Re: post-release package update policy
It seems that many people agree with me that we need both a stable
distribution containing stable packages that work together well, and a
bleeding-edge distribution containing the latest versions of things.
However, I'm beginning to think I'm a lone voice in the wind here,
when I point out that taking a snapshot of all the packages available
at a particular point in time is not a way to get a stable
distribution with packages that work together well.
I fail to see any point in having flag days, after which all updates
have to go into a separate directory. This will simply make it harder
to install the system we want most people to install (the stable
one).
Gary Huckabay writes ("Re: post-release package update policy"):
> I am a slackware user and I've been following this discussion fairly
> closely. As we all know, the major problem with slackware is upgrading
> from one release to the next.
>
> Slackware is extremely stable and it comes, "ready to run", right out of
> the box. However, it is a major pain in the arse to upgrade from x.y to
> x.y+1. You never know what to replace and so you end up replacing the
> whole darn thing.
>
> When I read the debian release, I became very excited because I thought
> the following was true: You would have a stable release which could be
> upgraded from x.y to x.y+1 _without_ major upheavals. What I have been
> witnessing on this list is very similar to the way slackware operates.
> Not good!
If you think that then you're not using dselect and dpkg in their most
powerful modes. If you have an NFS or local disk or CD-ROM copy of
the FTP site you can use dselect and dpkg to automatically upgrade
exactly those packages that have had new versions released.
In the future dselect will be able to fetch files by FTP, so it will
be able to work out which files to download too.
> Please, have a stable release, and an update site. Update the stable
> release say, every six months. In the interim, let the packages pile up
> at the update site where the rest of us can ignore them. However, don't
> forget your promise ... give us a way to get from y to y+1 without
> re-installing. If you can't figure out a way to do this, I would imagine
> the bulk of us will stay with slackware. Why change?
I think perhaps your problem is that you are having difficulty
figuring out which packages to *download* ?
Perhaps we should have updates directories, where packages are placed
*in addition* to being placed in the release. We would need to have
several, used one after another perhaps every 3 months. Packages,
when uploaded, would go into the main distribution tree but would
*also* go into the most recent updates directory. Every 9 months or
15 months or whatever we delete the oldest updates directory and its
contents, and make a new directory to be the most recent. So we have
/debian/debian-stable/
/debian/updates/1995.Apr-Jun
/debian/updates/1995.Jul-Sep
/debian/updates/1995.Oct-Dec
and whenever a package is uploaded it we put it in debian-stable and
also in 1995.Oct-Dec (and any versions of it in 1995.Apr-Jun &c are
deleted).
That way if you want to upgrade and don't want to or can't use
dselect's automatic features you just download the appropriate updates
directories.
Note that there isn't any problem with putting packages in the stable
tree to keep it up to date. This is strictly better than not putting
them there, even from the point of view of the amount of downloading
that needs to be done - remember that the only difference from the
point of view of people using the updates directories is that they may
have initially downloaded and installed a better version of whatever
package(s). They may have "wasted" the effort downloading the same
version again from the updates directory, but if we hadn't put the
update in the main tree they would still have had to download the same
package twice, only the first time they would have had a worse
package.
Martin Schulze writes ("Re: post-release package update policy"):
> If there is no stable release - a release that changes every day is
> not stable from users view - debian won't be used the way it would be
> otherwise. What users see is that there a new packages every day, and
> if they can't afford to get everyone they won't use Debian. (I know
> several of these, who would use debian if there would be an untouched
> release)
I don't follow you. What do you mean "if they can't afford to get
everyone they won't use Debian" ? Do you mean that they won't use it
if they can't download each new package as it is released ? That's
silly, and we shouldn't stop improving our release because of it.
Why don't they just download the release as it is when they want to
install it and use that ?
> If we don't get an untouched release then we will catch the Slackware
> syndrom, that is there are many different releases of 0.93R6 and if
> something's wrong one only can say on my release from xx.yy.zz
> everything's fine. :-(
This is missing the point. I think that trying to impose a version
number on the whole system is a *very* bad idea. It will artificially
tie us to this absolutely ghastly idea of having frozen snapshots.
When you report a problem you just report the version numbers of the
relevant packages on your systems - including the base disks, if
relevant. I think that the version number of the base disks used to
install the system should be recorded somewhere, together with a list
of which versions of which packages those disks contained. Whenever
reporting bugs in the basedisks you end up saying "I downloaded them
at date XYZ". But this is a separate issue.
Please, please - let us not have frozen snapshots. They'd be
terrible, from everybody's point of view. It's just a way to
immortalise bugs.
Ian.
Reply to: