Re: More FHS discussion (Was: Uploaded debhelper 2.0.09 (source all) to master)
Joey Hess wrote:
> I'm sorry Joseph, but you're trying to throw years of tradition out the
> window, and I just can't stand for it.
Ok, that's a bit curt and I apologize. Now that I'm actually awake what I
meant to say is:
We have always had partial upgradability as one of our goals, albeit one of
our more hidden and lesser-known goals, and have attained it to varying
degrees. Even during the libc6 transition, it was possible to partially
upgrade a system to unstable. You would end up upgrading perhaps 150 mb of
packages, but it was still a partial upgrade. Upgrading from unstable to
stable today may require a 100 mb download, but again it's still a partial
upgrade if you have 500 mb of packages installed.
But I think that talking about the size of the upgrade is missing the point.
The real point of supporting partial upgrades is that we have always made
sure that these different combinations of packages _work_. Dpkg always knows
about the dependancies necessary to ensure you have a working system when
you install a newer package. We have frequently bent over backwards and done
things the long, hard way to ensure this is true.
> When slink's epic4 had a DoS in the ANSI color parser the fix was "install
> potato's epic4"---but that couldn't be expected to work given potato is
> glibc2.1 could it?
Of course it could. Dpkg knows about glibc 2.1. "Depends: libc6 (>= 2.1)".
You relased a backported epic4 merely as a convenience to users, to allow
them to avoid a partial upgrade that may have been rather large and painful,
but was still a partial upgrade, and still something dpkg/apt could handle
quite well.
What you're talking about doing with this fhs transition is making it
possible to install combinations of packages that don't work correctly
together, and not telling dpkg about that. That is what I am opposed to.
--
see shy jo
Reply to: