sound problems

[Axel Thimm]

On Tue, Jan 06, 2009 at 02:05:17PM +0100, Kevin Kofler wrote:
> > This will even help Fedora, as the reason Debian/Mandriva introduced
> > them was for being able to cope with tons of packages when a
> > dependency does an sobump.
> 
> In Fedora we already have a solution for that, it's called a mass rebuild.

Oh, my middle name is mass rebuild. This is yet another feature I was
driving for in Fedora, to have scheduled mass rebuilds to do away with
issues like this and others, but mass rebuilds were consdiered only to
be done for really big changes (gcc for example). You can try to bring
it up though. Currently there are just no mass rebuilds.

> > Currently in Fedora whenever a package with many dependent other
> > packages changes soname, we need to go yelling around to other
> > packagers
> 
> Which is the right solution. Otherwise the packages will not benefit from
> bugfixes and improvements in the new version of the library.

A bumbed soname usually implies an API change. Some libs can be deep
in the depdency hierarchy. The issues have been recognized by now also
in Fedora due to the sheer size of it and we do have the first
incarnation libfoo-compat. This is just the first step to an versioned
libfoo<somark>.

> > and are only able to do an upgrade of this kind in rawhide. 
> 
> No, we can do a grouped update with a library and all dependent packages.
> (Buildroot overrides can be requested from rel-eng to build such grouped
> updates.) Of course this doesn't make sense for something which almost
> everything links, such as OpenSSL, but trying to upgrade such a library in
> a release is just insane, it makes much more sense to settle on a single
> version. Having packages require different versions of OpenSSL just because
> they happened to be built at different times is not helpful, one version is
> enough.

So, only rawhide. I'm talking about packages with many dependencies,
not libgphoto and gphoto (no issues against these two packages, just
the first that cam to my mind with little dependencies).

For example ffmpeg or similar packages would require almost a third of
ATrpms' package to be rebuilt.

> > See for example the x264 libs. Any 3rd party repo using them is doomed
> > to be incompatible to the other one. Unless we would all use
> > libfoo<so> style packaging.
> 
> Or unless the smaller repositories (e.g. ATrpms) just accept one large
> repository (i.e. RPM Fusion) as the authority

Yes, the authority question again. Please accept that not everybody
weighs the repos the same way you do. As packagers of these repos we
are doomed to be biased, but I'm trying to keep hierarchies out of the
game, can't you?

> > In a nutshell: This is done for better compatibility, not worse.
> 
> I know this is the intention, but in practice it is rather unhelpful and
> counterproductive. IMHO you should follow the Fedora guidelines closer,
> even where you believe them to be technically inferior.

Either way the issue is about say conflicting libx264 packages, the
libfoo<somark> is not causing any harm otherwise, there needs to be an
overlap to begin with. And in a monolithic build you have no chance at
all, with libfoo<somark> you can use foo-rpmfusion (including
libfoo.so.1001) and libfoo1002-atrpms for different consumers.

Of course when some people read foo-rpmfusion conflicts with
libfoo1001-atrpms they assume that the latter is wrong due to the
non-conventional name. If I dropped this packaging style you would
just have foo-rpmfusion conflicting to foo-atrpms and the bug reports
would level again. Actually it would be in my favour, I guess ;)
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090106/d4fb8d5f/attachment.sig>