[Slapt-get-devel] slapt-get and missing/failed sources

linux@nass-ek.de linux at nass-ek.de
Fri Feb 10 11:14:42 EST 2006


>
>Send Slapt-get-devel mailing list submissions to
>	slapt-get-devel at software.jaos.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
>	http://software.jaos.org/cgi-bin/mailman/listinfo/slapt-get-devel
>or, via email, send a message with subject or body 'help' to
>	slapt-get-devel-request at software.jaos.org
>
>You can reach the person managing the list at
>	slapt-get-devel-owner at software.jaos.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Slapt-get-devel digest..."
>
>
>Today's Topics:
>
>   1. Re: Proposal - handling of missing sources (Jason Woodward)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Thu, 09 Feb 2006 00:07:08 -0500
>From: Jason Woodward <woodwardj at jaos.org>
>Subject: Re: [Slapt-get-devel] Proposal - handling of missing sources
>To: slapt-get-devel at jaos.org
>Cc: denis at getopenlab.com
>Message-ID: <mailbox-26665-1139461628-337516 at jaos.org>
>Content-Type: text/plain
>
>Hi A.J.,
>
>> I would like to make a suggestion that would greatly increase the general 
>> usability of slapt-get/gslapt for ordinary users, based on the usage 
>patterns 
>> I perceive with my customers.
>> One of the things that most confuse them is why when a source fails, nothing 
>
>> else updates, in particular if that source is on removable media.
>> 
>> The current versions of slap-get will, if a source fails simply not update 
>at 
>> all. I believe it SHOULD if a source fails, just SKIP that source and still 
>
>> enable updates from other configured sources, this way one would not need to 
>
>> edit the sources to get a critical update form one server if another is down 
>
>> as you have to do at present.
>> 
>> Thoughts ?
>
>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?
>
hi,

imo there is a compromize : Could you tell the users, which source(s) failed ?

ie "Source No.1: ftp.fu-berlin failed , check your connection settings or review slapt-getrc!"

but i have no clue of the programming efforts.

rgds, manfred


More information about the Slapt-get-devel mailing list