Re: Are partial upgrades expected to work in rawhide?

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

 



> On Mon, Jan 02, 2017 at 02:29:47PM +0100, Florian Weimer wrote:
> 
> This is rawhide, if it breaks, people should keep the pieces.
>  We shouldn't
> change what we do with symbol versions just because of it.
> 
It has nothing to do with rawhide.  It is a best practice how to use
map symbols/version script and to have stable API/ABI
https://www.akkadia.org/drepper/dsohowto.pdf

quote:
>In short: a new
>version is defined for a new release of a DSO whenever
>new features are added.   The interfaces which changed
>in a compatible way get the new version associated.  All
>the other interfaces must not change and they keep the
>version they had in the previous release.
 
I know it is not a high critical issue and therefore I suggested  (in BZ) to
to automatically rebuild docker base image for such change in glibc in rawhide.
It would not fix the problem but it would reduce potential bugs. And in future
we might upgrade base modules for rawhide (if there will be any)

Another possible solution would be to patch the unreleased version with each build in rawhide
e.g. GLIBC_2.25 - > GLIBC_2.25_unreleased_$(date). So GLIBC_2.25  would be available only with official release.
I know that GLIBC_2.25_unreleased_$(date) would be different with each build but
that should not be a problem for officially unreleased snapshot of git master.
 
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[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