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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
