[Slapt-get-devel] Proposal - handling of missing sources
aj at getopenlab.com
Wed Feb 15 02:41:13 EST 2006
> That makes sense. The current behavior was based on the way apt-get
> handles the same situation. Also, when any sources fail, the package_data
> file isn't overwritten so that the current package data remains available.
> Maybe if only one source is present and it fails, the package_data isn't
> overwritten so that --show, --search, --list|available etc still work. But
> if there are multiple sources and at least one succeeded, the package_data
> file is populated with only the succeeding source. The main concern for me
> with this is that the failing package source would be the most important
> (say a slackware proper mirror) and the user somehow misses this and
> wonders why his package list is only showing a half dozen packages. I can
> see cons to both approaches. I still lean towards bailing on any failure
> so the user can correct a bad SOURCE entry or try another mirror. Maybe
> thats just what I would expect or prefer.
> Anyone else have any thoughts on this?
Hiya Jason, well let me explain a little bit about what OpenLab (well actually
OLAD) adds to slapt-get first, now for starters I kept all my code here in my
own project for one reason - upgrade compatibillity. It doesn´t make any
sense to add distro-limited features to slapt-get itself so it would not be
of use to you, but if I patched slapt-get just for me, I would have to
maintain that patch across new slapt-get versions, ergo I opted for outside
Within OLAD there is a button labeled ¨update package database¨ which
actuallly HAS to be run before the gslapt button is enabled, the reason for
this is that it doesnt JUST run slapt-get --update, what it DOES do is to
first scan the machine´s mount points to see if any of them contain a package
tree, if so, it adds this to slapt-getrc - so if you stick an OpenLab add-on
CD (say KARMAcd) into the drive firstt, it is automagically available to
slapt-get and gslapt.
So far so dandy.
Now normally, the update process will remove any such mounted sources if they
are not available, but that cannot be done quite perfectly because I HAVE to
use conservative code (I cannot risk accidentally wiping out a VALID source).
So if such a package source remains present, but isn´t actually THERE - then
the update now fails, because this happens BEFORE gslapt and slapt-get´s
output is hard to catch (where DOES it go anyway ?) it is very hard to report
back to the user the status of this, let alone doing it in a way my APP can
understand, so the user has no real idea why some new package he wants isn´t
So considdering this, I reckon there is another approach, something which will
be of use to ALL slapt-get users, so worth including in the main program
which will at the same time let us who work on add-on projects take better
advantage of slapt-get.
My new proposal is thus:
1) File:/// sources should be treated differently. If ONLY a file:/// source
is present, obviously it needs to fail if it´s not there, but if there are
multiple sources, file:/// sources should be considdered non-compulsory they
are in probably 99% of cases going to be on removable media, so slapt-get
should add them if they are there, and just cleanly skip over them if not.
2) With regard to other sources, currently slapt-get gives no scriptable
output on failures. I think slapt-get should if an external source fails
change it´s exit status. Default ¨all went well¨ status should be 0, it
should always finish running, but if any source fails, set some variable to a
number relating to the source position in slapt-getrc, e.g. the first SOURCE=
line would if it fail set the variable to 1, the second to 2 etc.
At exit tiime, pass your exit() call this variable, that way if sources fail,
any outside scripts or programs will know WHICH source failed and can try to
handle it intelligently. This could range from just an error message to
temporarilly commenting out the source before retrying depending on the level
of automation needed and what the user wants.
What do you think ?
"80% Of a hardware engineer's job is application of the uncertainty principle.
80% of a software engineer's job is pretending this isn't so."
Chief Software Architect
http://www.getopenlab.com | +27 82 726 5103 (South Africa)
http://www.silentcoder.co.za | +55 118 162 2079 (Brazil)
More information about the Slapt-get-devel