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.
Anyone have any information or comments on this?
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.
Anyone have any information or comments on this?
I don't personally see the big deal here... And it makes sense to label binary packages, since there is a good chance it won't run on say RHL7.3... Not too much different from RHL packages being labeled with 9 and such...
Anyways - Just my 5 cents worth of thoughts!
Rgds Thomas
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.).
But tags need to be standardized, and there was a looong and mostly neglected thread (End. of Sep. - Beginning of Nov.) about disttags but finally coming up with the fine solution of
rh7.3 < rh8.0 < rh9 < rhfc1
currently employed by many 3rd party repos with concurrent builds (drop the tag, if the package is really the same for all dists including the dependencies).
Anyone have any information or comments on this?
Search the mentioned thread above ("retaining upgrade paths", "disttags") and weep ...
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@wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]
On Wed, 26 Nov 2003, Axel Thimm wrote:
But tags need to be standardized, and there was a looong and mostly neglected thread (End. of Sep. - Beginning of Nov.) about disttags but finally coming up with the fine solution of
rh7.3 < rh8.0 < rh9 < rhfc1
Or because of backward compatibility:
rh73 < rh80 < rh90 < rhfc1 < rhfc1.1 < rhfc1.2
rh72 < rhas2.1 < rhel3 < rhel3.1
rh73 < rh80 < rh90 < rhel3 < rhel3.1
Depending on the situation. ;)
Thanks Axel ! -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]
On Wed, Nov 26, 2003 at 08:44:37AM +0100, Axel Thimm wrote:
But tags need to be standardized, and there was a looong and mostly
No, they don't. Not necessarily. When the tag is there for the convenience of the packager, it's the packager's job (within reason) to select the tag.
michaelkjohnson
"He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/
johnsonm@redhat.com ("Michael K. Johnson") writes:
But tags need to be standardized, and there was a looong and mostly
No, they don't. Not necessarily. When the tag is there for the convenience of the packager, it's the packager's job (within reason) to select the tag.
Such non-standardized tags will cause conflicts with automatic buildsystems. For a clean update-path a disttag-change is needed for new releases. What do you think happens at mass-rebuilds (e.g. rh9* -> fc1 transition) when every packager chooses an own disttag-scheme? Either, the packager would have to resubmit a new version (inclusive the QA trail) or the buildmaster would have to change the tags manually.
Both methods are not really an option, imo...
Enrico
On Wed, Nov 26, 2003 at 08:11:18PM +0100, Enrico Scholz wrote:
Such non-standardized tags will cause conflicts with automatic buildsystems. For a clean update-path a disttag-change is needed for new releases. What do you think happens at mass-rebuilds (e.g. rh9* -> fc1 transition) when every packager chooses an own disttag-scheme? Either, the packager would have to resubmit a new version (inclusive the QA trail) or the buildmaster would have to change the tags manually.
Both methods are not really an option, imo...
Sorry, I think I was operating on insufficient context. I was stuck in the base distribution -- Fedora Core, not third party repositories. Please excuse that...
Before I give any more pronouncements on this, I'd like to more carefully study the issues.
michaelkjohnson
"He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/
On Wed, Nov 26, 2003 at 01:20:28PM -0500, Michael K. Johnson wrote:
On Wed, Nov 26, 2003 at 08:44:37AM +0100, Axel Thimm wrote:
But tags need to be standardized, and there was a looong and mostly
No, they don't. Not necessarily. When the tag is there for the convenience of the packager, it's the packager's job (within reason) to select the tag.
On Wed, Nov 26, 2003 at 08:11:18PM +0100, Enrico Scholz wrote:
Such non-standardized tags will cause conflicts with automatic buildsystems. For a clean update-path a disttag-change is needed for new releases. What do you think happens at mass-rebuilds (e.g. rh9* -> fc1 transition) when every packager chooses an own disttag-scheme? Either, the packager would have to resubmit a new version (inclusive the QA trail) or the buildmaster would have to change the tags manually.
I agree, and to give another picture, imagine some packager eventually finding his currently used scheme inadequate, but would only be able to depart from it with epoch bumps, resulting in more versioning desasters.
Both methods are not really an option, imo...
On Wed, Nov 26, 2003 at 02:44:13PM -0500, Michael K. Johnson wrote:
Sorry, I think I was operating on insufficient context. I was stuck in the base distribution -- Fedora Core, not third party repositories. Please excuse that...
Even within the Red Hat ecosystem a standardized way to tag concurrent versions for different distros would not hurt. Currently it is really up to the (redhat.com) packager to decide on versioning. This freedom is sometimes used like an artistic freedom (yes, packagers are artists ;)
Before I give any more pronouncements on this, I'd like to more carefully study the issues.
Versioning (including disttags, epoch avoidance etc) should be standardized in any context IMHO. Of course there is more demand for doing so, if one needs to do often concurrent builds, which is not the main component in RH's development models (only a few common errata need to be treat that way from RH' POV).
Even if RH itself does not see great benefits in using disttags, they certainly do not hurt. And if the need for non-RH community content, like fedora-legacy or external repos is acknowledged, RH should be interested in having a common scheme, because - how do your marketing/sales folks say - it's important to have "one face to the customer" ;)
On Wed, Nov 26, 2003 at 10:34:09PM +0100, Axel Thimm wrote:
On Wed, Nov 26, 2003 at 01:20:28PM -0500, Michael K. Johnson wrote: On Wed, Nov 26, 2003 at 02:44:13PM -0500, Michael K. Johnson wrote:
Sorry, I think I was operating on insufficient context. I was stuck in the base distribution -- Fedora Core, not third party repositories. Please excuse that...
Even within the Red Hat ecosystem a standardized way to tag concurrent versions for different distros would not hurt. Currently it is really up to the (redhat.com) packager to decide on versioning. This freedom is sometimes used like an artistic freedom (yes, packagers are artists ;)
We put any tags far enough down in the revision number not to generate any need for epoch. We basically use suficiently consistent revision numbers, and then put any additional information beyond them off at the very end of the string, and they add information without creating an epoch problem.
michaelkjohnson
"He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/
On Tue, 25 Nov 2003 20:23:36 -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.
Anyone have any information or comments on this?
What I dislike about the FC1 tag is that it has come out of nowhere like a sudden strike. I mean, we've tried to discuss distribution tags several times before. It would have been nice if this someone, who has "invented" FC1, would have contributed to the disttag discussions.
--