rawhide report: 20080211 changes

[Michael Schwendt]

On Sat, 16 Feb 2008 05:35:21 +0100, Ralf Corsepius wrote:

> 
> On Fri, 2008-02-15 at 16:53 -0600, Jason L Tibbitts III wrote:
> > >>>>> "JK" == Jesse Keating writes:
> > 
> > JK> Erm, I should have restated, you can't conflict with any current
> > JK> package in Fedora.
> > 
> > That would be a new rule, then.
> 
> It's a silly rule 

It's not silly, but just a compromise. Convenience versus the
extras work needed to build a few packages with relocated headers
and devel libraries. More below...

> and renders the purpose of compat-packages widely
> non-applicable:
> 
> Consider this:
> 
> Given a package providing libraries:
> libfoo3: /usr/lib/libfoo.so.3
> 
> libfoo3-devel: /usr/lib/libfoo.so
> libfoo3-devel: /usr/include/foo
> 
> Now some other package needs libfoo.so.3's predecessor libfoo.so.2
> 
> One way to implement this would be to ship
> libfoo2: /usr/lib/libfoo.so2
> 
> libfoo2-devel: /usr/lib/libfoo.so
> libfoo2-devel: /usr/include/foo
> 
> 
> libfoo2-devel would conflict with libfoo3-devel, but the run-time
> package libfoo2 would not conflict with libfoo3.
> 
> This would allow users wanting to build packages against libfoo2 to
> alternatively chose between libfoo3-devel and libfoo2-devel.

This is like it has been done since the fedora.us packaging efforts.  It's
a compromise from times when clean buildroots were used to build packages
(aka "mach", later "mock").

Nevertheless, any conflicts between packages of the same dist are bad,
especially when they can cause fatal update scenarios, and also because
they require users/developers/admins to work around them when not using a
tool like mock always. WRT your example, you cannot guarantee that a user,
who has libfoo2-devel installed, will never be hit by a conflict with
libfoo3-devel during an ordinary yum update. This is because packages can
be pulled in as dependencies.