Re: Mirrors et al.
On Mon, 29 Apr 1996, Lars Wirzenius wrote:
> All these people have the same need: they must be able to say "Debian
> version FOO" or "Debian version FOO with all fixes as of YYYYMMDD".
> "FOO" can be 1.1 or 19960401 "Leonardo da Vinci" or whatever, it doesn't
> matter, but it must be unique, and it must clearly identify a known set of
> packages. Version numbers (of any format) and releases go together.
yep, I agree 100%. That was my point, but you explained it with a lot more
clarity than I did.
> > this is one of the features of the dpkg software - we should promote it
> > as such.
>
> dpkg is very, very nice and Ian J is my, well, perhaps not quite god, but
> at least an angel. (I don't say the same for dselect. I hate the UI.)
Actually, i was thinking about the whole package system rather than just
the dpkg program. yes, i agree here too...dpkg is great - it does it's
job and does it well. dselect's UI leaves a lot to be desired.
> Unfortunately, dpkg can't and doesn't solve all the problems. Say a few
> important packages are updated. Like the kernel and init. The new kernel
> changes something that breaks init, so if you upgrade the kernel, you must
> upgrade init as well. The maintainers of both are devoted to Debian and
> make new releases simultaneously. Unfortunately, the init maintainer
> has network problems, and can't upload the new version for a week. The
> kernel maintainer has no such problem, and uploads immediately.
this is the same situation as if someone downloaded the new kernel from
tsx-11 or sunsite or somewhere, compiled it and installed it only to find
that they now need new procps, new networking utils, new init, etc.
This requires the same care, attention to detail, and keeping abreast of
new knowledge as any other major change to the system.
it's a problem, and i don't see any easy way around it. in fact, i
don't think it can be automated 100%...at some point, user intelligence
and knowledge will always be required. My rule number 1 of computing:
if you don't know what you're doing, go slowly and carefully until
you learn what you need to know. Keeping my knowledge up-to-date and
relevant is, IMO, one of my primary duties as a sysadmin.
if the new kernel image is made to depend on some new software
packages, that will work only as long as the new versions aren't
dependant on functionality which is only in the new kernel. potential
deadlock situation of being unable to install sysvinit-9.9-9 because
image-2.5.108 isn't installed yet, and being unable to install
image-2.5.108 because sysvinit-9.9-9 isn't installed.
how would dpkg handle that situation? would it allow the install if and
only if both packages were available and selected for installation? or
would it just refuse to do anything?
> If there is a release, the new kernel would be put in unstable, making the
> unstable directory non-working. But that's OK, since that's what it's for.
>
> The release directory would be frozen, and would still contain a working,
> internally coherent set of packages, even if some of them might have been
> updated by other packages, and even if it might contain problems fixed
> by later packages.
yep, i think there should still be unstable and stable sym links, pointing
to code named directories.
my point was merely that the debian version number is arbitrary and
irrelevant, that people should be thinking in terms of package versions,
not distribution versions.
Craig
Reply to: