[Slapt-get-devel] Proposal - handling of missing sources

[A.J. Venter]

> 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 
wrapper code.

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 
showing up.

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 ?

Ciao
A.J.
-- 
"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."
A.J. Venter
Chief Software Architect
OpenLab International
http://www.getopenlab.com       | +27 82 726 5103 (South Africa)
http://www.silentcoder.co.za    | +55 118 162 2079 (Brazil)