[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: apt sources.list

> Mark Brown wrote:
> > Slink will disappear from the FTP sites once it is no longer the stable
> > release.  

	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.

	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 :) .

	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

	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.



Reply to: