FC1 tag in ethereal-0.9.16-2.FC1.1.i386.rpm

Dag Wieers dag at wieers.com
Wed Nov 26 08:59:43 UTC 2003


On Wed, 26 Nov 2003, Axel Thimm wrote:

> On Tue, Nov 25, 2003 at 08:23:36PM -0800, Nathan G. Grennan wrote:
> >   I don't like the idea of adding the FC1 tag to future updates, and
> > would love to see this update get replaced with an untagged version.
> 
> Tags are good for identification and enforcing upgrade paths for
> concurrent builds (e.g. the second build of ethereal 0.9.16 for both
> rh9, fc1, etc.).

Axel is right. If tags existed from the beginning (since RPM's inception) 
there wouldn't have been this 'DEB is better than RPM' or 'RPM is 
responsible for dependency problems' misconceptions. (Functionally there's 
really little difference between RPM and DEB)

People would have sticked to packages build for their system and would 
have known/seen that using (tagged) SuSE packages on Red Hat would 
consistently show problems where proper packages wouldn't.

Of course tags have little meaning if you're using apt. But still it is 
nice to do a

	rpm -qa | grep .rh9. | sort

Just to see what left-over packages are installed. (You can't do this on a 
clean upgraded Red Hat system ! You have to look at build-dates to 
determine something and even then...)

It would also be nice to have this information redundantly stored in an 
RPM header (Distribution-tag ?) in a standardized way. So that a package 
built to work for multiple distributions just has a list of these 
distro's inside.

For the same reason repo-tags are important to know where to complain when 
you have problems. Of course this information is also inside the package, 
still it's nice to tell in advance or without having to look inside the 
package. (Similarly as for the architecture-tag and the version-tag ;-))

Remember when SuSE removed these tags from their packages. A nightmare !

--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[Any errors in spelling, tact or fact are transmission errors]





More information about the fedora-devel-list mailing list