Re: Frozen distribution?
* Anthony Towns <aj@azure.humbug.org.au> [010216 19:43]:
> The easiest solution that I can think of (ie, that doesn't cause difficult
> to detect breakage, and that doesn't involve further significant changes
> or too much awkwardness) is, during the freeze, to just upload major
> changes to experimental, and bugfix updates to unstable.
Someone recently (in the last month or two?) asked ``why not use dpkg to
handle the distributions?'' though I am sure it was more eloquent. And,
given AJ's response in this thread, I am beginning to think that fellow
had the right idea, now that we have package pools in place.
[Remembering, of course, that although I am not 'in' Debian, I still
think of it as a 'we' situation. Call me nuts.]
Given that we now have packages located on our servers with names such
as: /pub/debian/main/packagepool/a/alphapackage-3.4-5-i386.deb
These names will allow us to keep several different versions of each
package in the package pools. This is important.
We generate several meta-packages -- lets call them
debian-release-slink, debian-release-potato, debian-release-woody,
debian-release-sarge, etc, as well as debian-frozen and debian-unstable.
The debian-release-* meta-package will Depend or Suggest or Recommend
the packages that were ``known-good'' at the time of release.
debian-unstable would Depend/Suggest/Recommend on the bleeding edge
packages. debian-frozen would D/S/R on the packages intended to go into
the next debian-release-* package.
Changing the dependencies for the various metapackages would 'upgrade' a
package -- unstable's dependencies could jump large versions, while
incremental bug fixes intended for debian-release-* (security patches),
debian-frozen would just cause the dependies to increment small
versions. This way, unstable can remain that way, and the other two have
some semblence of stability.
Of course, apt would need a switch (heck, it probably already has one,
it does so much already :) that would allow it to upgrade/change
packages only if the version number in the D/S/R of the appropriate
meta-package is updated (rather than follow the information it knows
about newer versions packages). Also, it would need to be modified to
not require that all packages listed in the D/S/R line be installed, but
if any versions of installed packages are updated, update those.
I don't think these changes would be difficult. (Ah, the joys of not
being the guy in charge of whatever it is I suggest be changed..)
An alternate strategy is to include in each package description (in the
_Packages lists) a header claiming the distribution it is intended for.
Listing three versions of a package in the one file, each one tagged
with Flavor: stable or Flavor: unstable or Flavor: frozen, with an apt
variable to choose which of the three to install. (Global variable is
probably the best idea.)
This alternate strategy would also allow major version number increases
in unstable, and minor version number increases in frozen and stable.
The downside of course is that this list would be huge, and each user
would be required to download the whole mess daily (if the user is like
all the users I know :) -- some sort of diff or delta version would be
splendid.
Though to tell the truth, I don't know why the old system (`old' meaning
`about six months ago') couldn't handle this.
Completely unrelated: I think some people could go for a
``stable-unstable'' version of Debian. If the _Packages lists would
include the date the package was installed (epoch time would be easiest
though not very human-readable) into the archives, then apt could be
configured to install only packages that have been in unstable for X
days, where X is probably about 7. This way, only packages that haven't
been removed in X days due to some strange error are installed. (Strange
error being ``mutt linked against non-existant library'' that plagued
Marco the other day; Marco quickly replaced mutt, and users running the
stable-unstable version would never have noticed.)
Is it possible to roll both ideas into one elegant solution that doesn't
cause the apt team to want me dead? :)
--
Earthlink: The #1 provider of unsolicited bulk email to the Internet.
Reply to: