On Fri, 2004-05-14 at 11:07, Axel Thimm wrote:
> > but you can simply do the obvious and append the release to the
> > existing one, like in:
> >
> > last rel: "3", next rel: "3.1"
> >
> > or for the sake of being talkative to users maybe even:
> >
> > last rel: "3", next rel: "3.fc1.1"
>
> But these _are_ disttags! :)
Still ugly, but I admit that packagers using them should use the same
hwen referring to the same distro-version.
> > > o it will enable Red Hat to have decent common errata for multiple
> > > non-EOLed releases.
> >
> > How do we not have that today?
>
> Don't ask me, have a look at the differnt (read per package) solutions
> used at Red Hat/Fedora Core for common errata (e.g. kernel, glibc,
> ethereal). Some packages got a ".7", ".8", ".9" appended, others an
> "FC1" etc, even others simply enumerated them.
I meant that whatever the release tags of the packages are is in no way
relevant to the errata package being decent or not. As I mentioned in my
last mail, I can suffer a little ugliness but be that as it may,
packages will work (or not) regardless of how shrewdly we build our
release tags or not, as long as v-r is rising strictly monotonously for
RPM.
> If there were policy, you could use foo-1.2.3-4.fc1.i386.rpm and
> foo-1.2.3-4.fc2.i386.rpm for pushing out common errata for FC1 and
> FC2, w/o reinventing the wheel each time.
I wouldn't put "incrementing a number" in the vicinity of anything
"invention", look at the USPTO where this got us ;-).
> > > o it will enable rawhide to have good upgrade paths for unchanged
> > > packages, e.g. bump the disttag from fc1.90 to fc1.91 to rebuild all
> > > packages for test2.
> >
> > As long as either the release itself or one component is an integer,
> > bumping that is easy. In fact it works today, ask Elliot -- I don't
> > think he fiddles manually with hundreds of release tags when doing a
> > mass-rebuild.
>
> No, that would be suicide, but the bumbed Release tag is not helpful
> for investigating what has changed. Sometime the %changelog is
> helpful, other times one need to open the packages and compare
> content. A changing disttag with otherwise invariant buildid doesn't
> even need a changelog about rebuilding.
Nah. I don't want the release tag to be meaningful at all, that's what
changelog is for. By codifying disttags into release, you practically
limit yourself to rebuild only when the distro-version changes and
believe me, we build more often and for much more purposes than only
this.
> > > o it will provide a coherent specification for Red Hat and third party
> > > repos to use. Asking of repos to change/apply vereioning specs w/o
> > > Red Hat to follow is not going to work.
> >
> > I think we're talking about Fedora Core and 3rd party repos, let's make
> > that distinction even if Fedora Core development is largely staffed with
> > Red Hat people today. My impression is that Fedora Core objectives in
> > this issue are to work inside of Core/Extras/Alternatives however these
> > are defined, anything beyond is "out of scope". That's my personal
> > opinion.
>
> Well, the thread started about someone wanting to provide packages for
> third party repos or Extras with disttags. If you look at fedora.us,
> which is deemed ti become Fedora Extras, you will see disttags. Are
> you suggesting to remove them? fedora.us developers would not be happy
> about that.
I would leave disttags to the package maintainers discretion, perhaps
within certain limits imposed by the build system.
> > > The downside is that someone must spent a day and a half to get the
> > > build system at Red Hat to add disttags.
> >
> > Obviously you are joking, but then you haven't seen our build system
> > yet, have you?
>
> Of course, I am joking. OTOH there are existing buildsystems in
> various projects including ATrpms, fedora.us, Dag and probably more
> that have solved this a long time since. So it is not really rocket
> science, once a disttag scheme has been approved. Perhaps you should
> hire me ;)
You wouldn't be content with what I can offer you as a salary (speaking
strictly as a private person) ;-).
> > > Disttags are a good concept. The only thing hindering them in the
> > > Fedora/RHEL world is the choice for a specific implementation. If the
> > > vendor does not go along, you will continue to have anarchy in
> > > guidelines.
> >
> > In my point of view, disttags serve only one purpose, namely
> > differentiating from which repository a package comes in the file name,
> > at the price of looking ugly.
>
> Oops, I understand that we are probably talking about different
> things. What you are thinking of are "repotags" like "fr", "at",
> "dag", "ccrma", "spc", "dries" that only serve for uglyness and have
> no functionality. I am not promoting their use, they shoudl be
> considered optional and should stay out of our way (in an upgrade
> path consideration, e.g. shove them at the very end of the release tag
> if you really must so).
Understood.
> > If I were to "usurp" a package for Core, I would only want to ensure
> > upgradability for that package eventually existing in Extras, for which
> > simple integers as releases suffice, [...]
>
> You should think outside of the Fedora Core scope where disttags are
> indeed only useful for common errata with simultaneous non-EOLed
> releases.
>
> Projects very near to Fedora Core (not "3rd party") like Fedora Extras
> predecessor fedora.us, and fedoralegacy.org do require more often to
> have common builds differentiating in the release built against. So
> disttags are required.
Not necessarily. When discussing build systems, more than once the idea
popped up that the maintainer shouldn't care about the release and that
it would be autogenerated. These kind of build systems would be fed from
a revision control system where you would put different distro-versions
into different branches. How the build system generates release tags
from that is a matter of discussion, but nothing the package maintainer
should have to care for then.
> And as a community project you cannot keep out of scope "3rd party"
> repos. They also support multiple releases of Red Hat and Fedora and
> ths need disttags (not repotags!).
Not in my opinion.
> And really, disttags do not hurt at all. Aesthetics don't count in
> packaging, otherwise we would package foo-1.2.3-4.el3.at.i386.rpm into
> setup.exe.
Replacing ugliness with abomination here ;-)?
Nils
--
Nils Philippsen / Red Hat / nphilipp@xxxxxxxxxx
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
Attachment:
signature.asc
Description: This is a digitally signed message part
