Re: Use bash patchlevel as part of RPM version?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Apr 21, 2009 at 01:02:50PM -0500, Callum Lerwick wrote:
> On Tue, 2009-04-21 at 09:02 +0200, Roman Rakus wrote:
> > There is a bug (#496780) requesting to use patchlevel of bash as part of 
> > RPM version. So today bash-4.0-6.fc11.i586 would be 
> > bash-4.0.16-6.fc11.i586. What do you think about it? Could it break 
> > anything?
> > RR
> 
> General rule of thumb is follow what's in the tarball filename if
> possible. And the patchlevel isn't in it.

The release process model of bash is "lazy", they only release a full
tarball if the diffs are large enough (or the accumulated sum of
them).

> But putting the patchlevel in somewhere isn't a bad idea. I'd go with
> something like this:
> 
> bash-4.0-1.pl16
> bash-4.0-2.pl17
> bash-4.0-3.pl18

So what would you do when upstream does consider releasing
bash-4.0.25.tar.gz, then again just uses patchlevels for say up to
bash-4.0.33.tar.gz, then goes bash-4.2.tar.gz and the story begins
anew?

Technically following the guidelines to the letter we would get

bash-4.0-3.pl18
...
bash-4.0-4.pl24
bash-4.0.25-1
bash-4.0-1.pl26 (epoch bump!)
...
bash-4.0-6.pl32
bash-4.0.33-1
bash-4.0-1.pl34 (again epoch bump!)

Guidelines and laws can be interpreted in many ways, but even in court
the intention of the law is important - the post-release versioning
for *NON-NUMERIC* patchlevels, which BTW is here not the case, bash
upstream never adds a "p" or any other letter) serves for keeping sane
upgrade paths w/o introducing new epochs and if we were to follow it
to the letter we would indeed achive the opposite.

The official patches by upstream do intenionally increase the version
of the source and bash --version reflects that. So upstream's
intention is that this source conglomeration is bash-4.0.17, not
bash-4.0 with some patches.

I'd say either add the patchlevel to the version like the bugzilla
requests it (because that's were it belongs, the
stuff-it-as-as-suffix-to-the-release-tag workaround is just a
... workaround), or leave it as it is.

Whatever the outcome, for F11's release I wouldn't touch bash
anymore. If there is something to fix do it as an update, or for F12.
-- 
Axel.Thimm at ATrpms.net

Attachment: pgpVOI1KU5fC6.pgp
Description: PGP signature

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux