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(a)redhat.com
"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