On Thu, Jul 08, 1999 at 11:58:40AM -0700, Joey Hess wrote: > 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.
Okay, then we have a slightly different definition of "partial upgrade"
here...
> 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.
Okay, I had no intention of not having dpkg be fully aware of the versions
of certain packages required to upgrade safely. That is necessary for ANY
UPGRADE as far as I'm concerned, not just a partial one. If we put some
script or program in a package that all packages uploaded afterwards will
expect to be present, most certainly a dependency should be declared. I
wouldn't have it any other way.
The test for the existance of the script/program in the postinst would be
there for making sure when our transition phase is complete the symlink
manager can go away.
> > 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.
You're right, a dependency on whatever pacakge provides the symlink
manager should be declared. However the reason to test for it in the
postinst/prerm is forward-thinking, not backward. if the symlink manager
doesn't exist and the version of the package which will provide it
(debianutils?) meets the dependency, the postinst/prerm assumes that we
have made the transition and the compatibility symlinks are no longer
necessary.
--
Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux developer
PGP: E8D68481E3A8BB77 8EE22996C9445FBE The Source Comes First!
-------------------------------------------------------------------------
<Crow-> Manoj: well, i cant understand stuff like "s/3#$%^% {]][ @ f245
}"
<Manoj> Crow: That is not quite legal ;-)
<Knghtbrd> Manoj - how would one make "s/3#$%^% {]][ @ f245 }" legal
anyway? (and what would it do? hehe)
<Manoj> Knghtbrd: You need to finish the s/// expression.
<Knghtbrd> oh, is that all?
pgpx4Vyo2aPAe.pgp
Description: PGP signature
