Re: apt sources.list
> Mark Brown wrote:
>
> > Slink will disappear from the FTP sites once it is no longer the stable
> > release.
Problem:
When potato defrosts and becomes "stable", machines using
the stable branch will quantum jump into a new release, whereas their
owners prefer a gentle and more stable transition (they choose to be stable).
No current setting in apt sources list will give a gentle transition.
Goal:
During mirror transition from stable->slink to stable->potato that
machines do not do a quantum jump into the new release unless that's
what the user wants.
Apt-get update-dist requires confirmation before massive changes.
The user should be informed why there are all these changes, and
what to do about it.
Possible solutions 1:
For automated updates: wrapper for apt-get dist-upgrade
if package update count > N, only retrieve a minimal upgrade
set less than N, equivalent of an automated "apt-get
install `Package in list`" . After a number of calls the whole will be
up to date. This would be very useful for upgrades where lack of
disk space is a factor, having the whole system in .debs
in /var/cache/apt is not fun. This keeps stable
as a basically static entity. This is only pain reduction.
Possum bile solution 2:
(describes a particular package pool to address this problem)
A new symbolic link tree and is basically a walking stable (dynamic).
Following the walking stable you would upgrade gradually.
ALL dependencies are resolved above and below (the details of this
could be hard since a single offending package would keep a whole
branch old), apt is capable of figuring out the dependencies.
Candidates for walking stable would be:
1. nominated by their maintainers for stable (nothing new)
2 approved by N people - (rejects x 2)
(the rejects could be the bug tracking system)
I know, putting a democratic process into it muddles it up.
What this could achieve is putting essential, but known
flawed packages in the release.
3. been in the archive for period T (with no modifications)
(some packages would never make it in as appropriate).
Exceptions only for security releases.
(this idea of course lacks complete integration testing,
so maybe point release candidates from this Might work).
Precipitate 1:
How about keeping Slink for one point release after Potato is the
stable release? I don't think it would change disk usage on the mirrors,
(by not being freed that is). Then when one sees that "the whole
damn thing" is supposed to be updated, they can use slink to
get by until they can upgrade to potato. They would have to
manually change their apt sources list to point to slink,
death-watch->slink. This won't help the newbie, unless there is
an essential package that will tell them what's going on,
and inform of the change over (yecch, just because I offer the
idea doesn't mean I have to like it).
Precipitate 2:
Make apt "release" sensitive, so that it "knows" that
stable->slink, and there is a frozen potato out there waiting to
make it obsolete. How would this be presented to the user? Maybe
as a warning message when apt is run that the user is changing
releases, so that when stable transitions
further upgrades are a release change. Yea, dumb idea....
it sank to the bottom :) .
Constraints:
Mirrors - we cannot keep old unsupported releases around forever,
CDs are great for archival use.
The time it takes to produce releases is only going to increase as
the complexity of the system increases.
For those who want a static release (versus stable) the
education of the user is (not) done when selecting the apt source list
and they should be directed to choose by name, rather than the symbolic
stable and unstable. If they choose not to decide, the default
stable is their choice.
Should I start working on package pools, I don't see anything on devel
about any progress? (this is a request for a status, where should I be
looking.)
Note:
With systems that are walking upgrades, restores are a pain
since you are restoring on to a system with a different
kernel, libraries etc... restoring libc is usually the
last thing before someone hits reset (please don't tell me
about sash), Upgrading a system before restoring is time
consuming and one more step. Making recovery disks is
just forgotten, I want bootable backups :) .
It would be interesting to compare mirrors loads upon the
change over to stable, might give an indication of the number of automated
update machines using stable to see if this really is an issue.
Sincerely
J.Currey
--
<SNIP>
Reply to: