Package naming conflicts (was: Re: sound problems)

[Horst H. von Brand]

Michael Schwendt <mschwendt at gmail.com> wrote:
> On Tue, 6 Jan 2009 14:32:40 +0200, Axel wrote:
> > On Tue, Jan 06, 2009 at 11:24:07AM +0100, Kevin Kofler wrote:
> > > Axel Thimm wrote:

> > > > Incompatible to what? If there are conflicts between ATrpms' packages
> > > > and others from the N thousand official packages, please report
> > > > them and we'll fix them.

> > > One concrete source of incompatibility is that you use Debian-style
> > > versioning (e.g. libquicktime0) for some library packages, which is
> > > against Fedora guidelines (in fact, IIRC a guideline change you
> > > proposed to that effect was rejected) and which can confuse yum in
> > > some cases.

> > I think it was rather forgotten and withdrawn, but that's rejected
> > nonetheless.

> > The reson I use these conventions is because they actually increase
> > compatibility: When repo X, repo Y and repo Z (one of them may be
> > Fedora, the others two 3rd party ones) have built foo, baz and wuz
> > against libbar.so.1, libbar.so.2 and libbar.so.3 these runtime
> > packages make sure that they can all coexist w/o one repo enforcing a
> > full rebuild on the other.

But using one convention here and a different one there /creates/
confusion.

> Without proper Obsoletes/Provides in both directions (i.e. Fedora <-> 3rd
> party repo), it doesn't work flawlessly. libbar3-3.0.1 will conflict
> with libbar-3.0.2. AFAIK, this has happened several times before.
> Additionally, you need to take precautions and relocate files in
> several packages for them to become parallel-installable.

Right. And that is a distribution-wide decision.  BTW, I do agree with the
Fedora folks here: Making sure everything works with /one/ set of libraries
(or other assorted packages) is hard enough as it is. It means there is
system-wide breakage if something like Python is updated, sure. But that
can be inflicted upon rawhide users, and the result of shaking out the bugs
shows up at most some 6 months later. It is not that regular users have to
wait for untold years until random updates are in mainstream Fedora.

> > 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.

> Without a doubt. If done properly, it would fix the poor broken deps
> caused by sudden/unexpected soname bumps.

No, it doesn't. It just forces carrying outdated junk around forever, stuff
that needs the same care as new packages (and tending for old code is more
work, and unexciting work at that). Better do a clean cut with the past; if
some dependencies can't be updated for now, so be it. yum is currently able
to handle this scenario just fine.

> > Currently in Fedora whenever a package with many dependent other
> > packages changes soname, we need to go yelling around to other
> > packagers and are only able to do an upgrade of this kind in rawhide.

So?

> This is also due to koji buildroot protection and overrides.
> Some packagers believe they must push a soname bump to stable before
> they can rebuild dependencies. They feel embarrassed when they learn
> that they can request releng to set an override-tag and then prepare
> a group update for bodhi. Features and procedures are not known enough
> and are hard to find in the Wiki.

Suggest updated guidelines then.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  +56 32 2797513