* 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.
