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

Install methods reshuffle [was:Re: Debian 2.0 install]



Since this has sort of been brought up, I'll throw one in for the wishlist,
though it may already be possible in some form with apt.

I operate a LAN here.  Which, as I'm happy to class it as experimental, is
very often closely up to date with the latest 'unstable' release of debian
and Linus' kernel releases..  Often new packages are installed or upgraded
ones are tested, on a daily or almost daily basis.

As such, the machines on it ( currently all x86 variants ) are often not in
total sync regarding which versions of various packages they may be running.
Upgrades of system critical packages are often tested on a single machine
before it is considered 'safe' to propagate them to the other machines on
the network, usually greatly minimising the effort required to back out
any packages suffering from 'late-night-itis'..

However, for the majority of them, which install with no serious glitches,
there would appear to be no seamless method ( via the dselect frontend at
least ) of also installing these across the network into other machines
without some degree of manual ( or scripted ;) intervention.

The machines are not identical in the setup they run, even when they are
in version sync with each other, so simply mirroring the /var/lib/dpkg
tree ( while it still contains the .debs I wish to propagate ) causes
problems of it's own, and mounting it across the network via NFS or
some similar method, would seem to suffer from the non-existence of
the Packages.gz files, which the 'Upgrade available packages via ftp'
method, do download, process and then delete.

While the network friendly method of working around this might involve
'hand' copying and installing the relevant .debs to various machines,
or linking the /var/lib/dpkg tree into my local ftp or web space(Yecch)
the Time friendly method ( my time that is ;) is to simply let dselect on
each machine do it's own independent thing.

It's not hard to see that this duplication of network traffic represents
a needlessly increased load not only on my portion of the network, but
significantly more so perhaps on the debian mirrors.

A squid proxy or something similar might keep this traffic local to me,
but a more elegant solution integrated into the debian package management
system, enabling network wide but staged upgrades with a single fetch from
the mirror sites would certainly be an Efficient Thing IMHO.

best,
Ron


--  
To UNSUBSCRIBE, email to debian-testing-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Reply to: