Debian Freezing

An anonymous reader wrote in to alert us to that fact that Debian is scheduled to Freeze this weekend. Soon there shall be spuds for everyone. This of course means that I will continue to recklessly apt-get upgrade on my laptop with reckless disregard for the safety of anyone within a 20 yard radius of my sofa.

Comments

That's apt-get *dist-upgrade*...

[Paul Crowley]

for those running Slink who don't want to destroy their system.

Hope this helps (and don't let those spud gun pellets moulder down the side of the sofa)...
--

Automated Debian Management

[Christopher B. Brown]

There's not a precise equivalent to Kickstart; what I would do, if I wanted 13 identical boxes, would be:

• Pick one box as a "master," and install everything that you want installed on it.

  I would mount my Debian CD on a separate box and download via HTTP; this has the result of pushing all the packages that got installed into /var/cache/apt/archives

• Then, add /var/cache/apt/archives to /etc/exports so that it gets exported to other machines that want it.
• Install the "base" Debian stuff (about 6 floppies worth of stuff) on those other machines.
• Copy over some base networking files ( e.g. - /etc/hosts , /etc/fstab and such) and drop them into place so that each machine has some basic common configuration.

  I would tend to want to use cfengine for this; I have yet to get it configured to distribute files itself, which is something it claims to be able to do...

  Inserting extra needed lines in config files like /etc/fstab is the sort of thing that cfengine is ideal for...

• Mount the relevant filesystems on the remote machines, and then have them install via: # dpkg -i /mnt/common-apt-cache/*.deb

  This gets all the machines to have the "common" stuff.

• It would make a lot of sense to either build a .deb package containing any common config scripts/files or provide a common NFS-mounted "export" directory like the "apt package archive" as a conduit to push stuff to the remote boxes.
• Set up a cron job on each box that (let's say) runs a script in /mnt/common-config/ that installs any .deb files in /mnt/common-apt-cache/ that are less than a day old (or check against what's installed).

  I would most definitely try to implement this using cfengine as it's designed to do this sort of thing...

This is definitely no harder to automate on Debian than it is on RPM-based distributions, and could actually be easier as you could set up a local "package archive" for the whole set of packages and use apt-get hitting a local server rather than a remote one to keep all of the packages up-to-date with what you want on them.

Look at cfengine; the Usenix journal ;login has had a series on it recently; it is really powerful.

This is premature.

[Lalo Martins]

The freeze isn't officially announced. It isn't officially decided. It probably won't happen, because one of the people who think it's too early is our Project Leader, Wichert Akkerman.

Basically the point is that some (me included) don't want to freeze without working boot-floppies (the installation program suite, for those not too deep into Debian) and with a lot of new packages stuck in Incoming.

(Yes, I am leaking information here. But my intention is to fix another lack, because a leak of correct information is IMHO better than a leak of misinformation.

Freeze E-Mail

[Accipiter]

Here is an E-Mail from Richard Braakman regarding how the freeze will work.

Date: Tue, 2 Nov 1999 23:36:59 +0100
From: Richard Braakman
To: debian-devel-announce@lists.debian.org
Subject: Status of Potato

(Please send followups to debian-devel, not debian-devel-announce)


Potato looks ready to freeze. Its primary goals have been achieved,
and the only things left to do are to finish the bootdisks and fix
lots of bugs. I think it is advisable to freeze now, before we
start major new developments in potato.

Last weekend has shown that the bug count can be reduced rapidly
in intense sessions. We'll need more of those, and probably a large
number of packages will also have to be removed from frozen.

The freeze will be the coming weekend, on Sunday, November 7th.

Before the freeze, we will have to deal with the backlog in Incoming
somehow. There are more than 200 packages in it now and it's growing.
Help is on the way, but probably not in time. In any case, I do not
think it is wise to install a hundred new packages just before the
freeze! My plan is to handle all the packages that fix bugs, and
leave the rest for the new unstable.

After the freeze, I expect it will take a week or two for frozen to
settle down. A lot of bugs can be fixed in that time. This period
will be similar to the traditional freeze.

Then we can start with Test Cycles. These will address the problems
we had with the previous two freezes. A Test Cycle looks like this:

1. Boot disks and CD images are created.
2. The distribution is tested for a fixed amount of time. No changes
of any kind will be made to frozen during this time. Fixes for
problems that are discovered will of course be prepared, but they
will not be installed yet.
3. The results are evaluated. If the distribution is good enough to
release, it is released as it is.
4. Otherwise, fixes are installed, and if necessary, extra time is
taken to fix the problems.
5. New boot disks and CD images are created, and the cycle begins again.

Richard Braakman

-- Give him Head? Be a Beacon?

Re:Use of Debian

[rcw-work]

#1. Not yet. But the idea is to make debconf be able to answer questions from an SQL database, a file accessible via HTTP, whatever, to replace asking questions at the console.

#2. This is open to discussion, although most people with an opinion on the subject say apt-get/dpkg eats rpm for lunch. Both have severe deficiencies, but to me dpkg has fewer of them.

For the equivalent solution with apt-get, you could make a directory on a server somewhere, run dpkg-scanpackages when you update something on that server (this creates the Packages file), and then have apt-get update; apt-get install packagename run every night from cron. That would update that package only.

Or, if you don't have any complicated dependancies requiring automatic installation ordering (it doesn't sound like that) you could replace the 'rpm -U *.rpm' in your cron script with 'dpkg -i *.deb' :)