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

Re: Package Pool Proposal



On Wed, Dec 08, 1999 at 06:35:09AM -0500, Michael Stone wrote:
> On Wed, Dec 08, 1999 at 09:21:03AM +1100, Craig Sanders wrote:
> > On Tue, Dec 07, 1999 at 05:57:23AM -0500, Michael Stone wrote:
> > > On Tue, Dec 07, 1999 at 11:47:59AM +1100, Craig Sanders wrote:
> > > > it seems like a very reasonable and responsible use of bandwidth to me.
> > > 
> > > Seems to me that most people don't use all of the packages in debian,
> > > and are going to end up repeatedly downloading packages they'll never
> > > use. Seems far more responsible to use a web cache or shared apt archive
> > > directory and only download that subset of debian that's actually used. 
> > 
> > yes, that works well for some (perhaps most) people.
> > 
> > it doesn't work all that well if:
> > 
> > a) you install different packages on different machines
> 
> Why not? In that case you're only downloading the packages once per
> machine anyway--how is that more efficient if the packages are mirrored
> rather than cached. Unless you're installing *all* packages on at least
> one machine, the mirror is still less efficient.

stop jumping to conclusions.  i didn't say it was more *efficient*.  i said
that the *convenience* of having a local mirror was worth it.

> > b) you want to be able to nfs mount your debian mirror so you can install
> >    with dpkg -i as well as apt-get and dselect (this is particularly
> >    useful if you mirror debian-incoming as well)
> 
> Use apt-get -d to download but not install. 

i know how to use apt-get.

> I'm not sure why this is necessary, but what the heck.

because sometimes you can avoid having apt-get or dselect re-install a
whole bunch of stuff by manually using dpkg to install the one package
that everything else is waiting on.

because soemtimes apt-get gets it wrong (or at least, not-quite-right),
and manually installing packages with dpkg is the best thing to do.

because sometimes i know exactly what package i want to install and
exactly where it is, and i couldn't be bothered waiting for 'apt-get
update' to run.

because sometimes it is essential to minimise downtime by manually
installing certain vital packages first, rather than hoping that apt-get
will install in a reasonable order. apt-get has no way of knowing
which packages are vital to my server, it orders installation solely
according to dependancy information...and sometimes that means that
vital packages are in iU (installed, unconfigured...i.e. not running)
state for ages while less important (from my subjective POV) packages
are being installed.

even if it takes me 10 minutes to figure out the dependancies on paper
so that i can manually install these packages first with dpkg then it is
worth it.

automation is a tool, not a strait-jacket. use it where appropriate, but
don't limit yourself to only what it can do.


> How often do you really need something out of incoming but can't wait
> till it gets in (and can wait until your next mirroring session?) 

quite often. whenever the package in the main archive is broken in some
way and i need to install the fixed one from debian-incoming RIGHT NOW,
and not in two days time when it has made it's way into the apt-able
main archive.

> But at least you can now download *every package* *twice* for *every
> version*. :-/

yes, this consumes extra bandwidth...but i have found over the years
that it has saved my arse often enough that it is worth it.


> > c) you want the downloads to occur overnight when you're not using your
> >    internet link.
> 
> I forgot, apt-get -d can't be stuck in an at or cron job.

dselect can't be run in a cron job.

i don't like or trust 'apt-get dist-upgrade'. i use 'apt-get install'
to install a handful of packages and 'dselect' followed by 'apt-get
dselect-upgrade' for full upgrades. using dselect to manually
select/unselect packages and resolve conflicts etc caused by package
splits & renames is the best way to avoid problems during upgrade.

on systems where i don't mirror debian (e.g. client machines at the
end of a modem or 64K ISDN link), i run dselect, then run 'apt-get -d
dselect-upgrade' overnight, and then come back in the morning to run
'apt-get dselect-upgrade'.

in other words, i know how to do it...i do it often. it's necessary on
systems without a mirror, but i see no reason why i should limit my more
capable (i.e. better connected) machines to that when by running a local
mirror i can have far greater convenience during upgrades for all debian
machines on the LAN.

> > d) you want to upgrade NOW because you have enough free time to do it,
> >    not in 10 mins or 3 hours time after the download has completed.
> 
> Whoops, you've gone from 'mirroring is a responsible use of bandwidth'
> to 'I want instant gratification.' :-) 

so what's wrong with instant gratification? i want (in fact, need) my
machines to be running NOW.

not everyone uses debian solely for personal workstations. many of us
use debian on production servers where 24/7 uptime is essential (in
fact, that requirement is one of the reasons for using debian - it's the
best distribution for the job)

when you've just heard about a serious bug in a package which is
essential to your business, then the difference between 5 seconds
downtime to install a package from your mirror and several minutes or
several hours downtime to download is significant.

even at approximately 20c/MB, the cost of downtime is far higher than
the cost of mirroring debian.

working at an ISP, the 10-50MB (average) traffic generated by my nightly
binary-only mirror run is a drop in the ocean. the real bandwidth
wasters are worthless crap like streaming audio or video - if people
want to listen to the radio then why don't they just buy one for $5 and
switch it on?


finally, no-one is forcing you to mirror debian. no-one is saying that
your choice to NOT mirror debian is "wrong". if you're happy with using
apt-get as you describe, then keep on doing that. your way is not the
One True Way<tm> of using debian...why don't you leave other people to
run their own systems and networks in the way that suits them best?

craig

--
craig sanders


Reply to: