Re: Library packages depending on data files
On Wed, Feb 04, 2004 at 06:15:27PM +0000, Colin Watson wrote:
> On Wed, Feb 04, 2004 at 07:08:26PM +0100, Adrian Bunk wrote:
> > On Wed, Feb 04, 2004 at 01:07:33PM +0000, Colin Watson wrote:
> > > Two words: upgrade hell.
> >
> > For whom?
> >
> > The most important thing is whether there are problems for the users,
> > and situations like being able to install libssl0.9.6 and libssl0.9.7 at
> > the same time are problems waiting to occur when people will do e.g.
> > partial upgrades from Debian 3.0 to Debian 3.1, since it might happen
> > that one application links (via a different lib) with two so-versions
> > of libssl at the same time.
> >
> > Compared to these user visible problems, I'd consider the issues like
> > having to recompile all packages in unstable and the babysitting testing
> > requires less important.
>
> No, we should just fix bugs (for they *are* bugs) in applications that
> try to link to two versions of the same library at the same time. It's
The problem is that they come through inter-library dependencies. It
might be that the program doesn't change, but a library is recompiled.
> not that hard to do normally, and we've got plenty of experience doing
> it. This is much friendlier to users than forcing them to uninstall half
Let's assume:
Package: proga
Depends liba0, libb0
Package: liba0
Depends: libb0
If liba0 is recompiled with libb1 and random segfaults are reported in
proga, the proga maintainer usually recompiles proga with libb1 and
everyone's happy ... but the breakage when upgrading only liba0 and not
proga is still possible.
I'm sorry, but I doubt every maintainer of proga will do the right thing
and add a conflict with older versions of liba0.
The problem with this kind of problems is, that many of them won't
become known until the next stable release when many people will do
upgrades and partial upgrades.
> their system during an upgrade, and guaranteeing that testing is even
> more permanently out-of-date than it already is.
As already explained in this thread, testing might be more out-of-date,
but it's also more consistent.
> If you know of cases where partial upgrades cause this problem, please
> report them. However, your proposal will make partial upgrades far more
> painful than they need to be.
I vaguely remember such issues at the libssl0.9.7 transition, but that
was more than a year ago.
> BTW, having to recompile all packages in unstable is a major, major
> deal, and we *have* to allow it to be parallelized with other issues or
> releasing becomes nigh-impossible.
This is only an issue with releases when a freeze is near.
I might have missed it, was there a date for a freeze announced, or is
there a planned date for a freeze for sarge [1]?
I was considering to help fixing bugs e.g. via organizing bug squashing
parties, but unless there's an at least light freeze [2] of unstable,
such an effort doesn't seem to have much effect.
Would it make sense that I sent my suggestions and how I'd help with it,
or does this conflict with any (realistic) release plan that already
exists?
> Colin Watson [cjwatson@flatline.org.uk]
cu
Adrian
[1] the last plan I remember announced the Dec 1st 2003 as release date
for sarge, and it seems to be quite obsolete
[2] "light freeze":
not a complete "no new upstream code", but no major new upstream
releases or new so-versions of libraries
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Reply to: