Re: Recommended upgrade procedure for >1 release upgrades

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

 



On Mon, Nov 21, 2016 at 4:54 AM, Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote:
> On Sa, 2016-11-19 at 08:56 +0100, Kevin Kofler wrote:
>> Adam Williamson wrote:
>> > I think I've proposed at least once that we make Obsoletes: for retired
>> > packages mandatory. My last proposal currently seems to be assigned to
>> > tibbs.
>>
>> IMHO, forcefully removing packages that still work is a major disservice to
>> our users and should never be done.
>
> That is a non-trivial effort though.  We would have to put the major
> shared library version into package names, simliar to debian.
>
> So, when the soname is bumped upstream a new lib${pkg}${new-soname}
> package shows up.  The old package lib${pkg}${old-soname} package can
> continue to linger around, and obsoleted packages depending on it
> continue to work and also don't block lib${pkg} updates because the
> update can be installed parallel.
>
> Of course this approach has its downsides too, like the more complex
> maintainance, lib*${old-soname} packages piling up over time, and
> probably more I'm not aware of ...
>

We do this in Mageia, and openSUSE does this as well.

However, while I agree with the idea of actually splitting
applications and libraries out more (packages like libxslt are
aggravating at times), I'm not sure it's useful to put the soversion
in the name, especially since RPM already generates a versioned
provide using the library soname. User-facing versions make much more
sense here.

For example, if foo 1.23 has libbar.so.5 and foo-exec, I would leave
foo with foo-exec and have libbar contain libbar.so.5. It's more
useful to users. If we want to have multiple versions, we can just
affix ${ver} to the name, as user-facing versions are comprehensible
to people. Few people understand what soversions mean, and fewer
follow them correctly.

And even with all this, this idea above is really only useful in the
context of a distribution that aims to maintain binary compatibility
across longer lifetimes. If we're able to keep moving forward and
properly integrate things against the latest versions of libraries,
then I don't see why we should affix versions or soversions to library
package names.

-- 
真実はいつも一つ!/ Always, there's only one truth!
_______________________________________________
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