Re: autoup.sh & considerations on bail-out scripts
On Tue, 10 Feb 1998, David Welton wrote:
> Hi, when looking through autoup.sh, I noticed something that may be
> a problem. to wit, it seems as if it depends on ncftp for its ftp
> method. First and foremost, this presents the problem that ncftp is
> not free (open, I guess I should say:-), and is not on our official
> CD. Second of all, I think it would be better to utilize something
> that is more commonly available.
yep. i was planning to rewrite that part of the script (contributed by
Turbo Fredriksson) using lwp-request from libwww-perl. Other replies
have suggested several other alternatives.
i also wanted to allow the user to select from a list of debian mirror
sites or specify their own.
it's pretty obvious though, that my time is limited at the moment (very
busy at work), so i think it's time i turned over the script to the
debian-testing list for further development. I like the ideas you've
written about David so if you'd like to take over the job of co-ordinating
development of autoup.sh, it's yours.
Like many people, I think that a package sets front-end for dselect is a
priority for the hamm release. if i get any spare time soon (unlikely)
I'll work on something for that.
BTW, one other thing I was considering doing was changing the 'user
interface' so that it uses dialog to ask questions. it would have to be
dialog (rather than whiptail). dialog is guaranteed to be on a bo system
(because modconf is required and modconf depends on dialog), whereas
whiptail needs libc6 and slang 0.99.38 which are only available for hamm.
> The other option would be to use perl somehow, possibly including the
> FTP module. This seems a bit cleaner, and still something that is
> available to most people, however, it will require more effort.
> These two possibilities are within my technical grasp, so, of course,
> I make myself available for implementation.
libwww-perl is your friend. it makes ftp:// and http:// fetches very
easy. it also comes with a program called lwp-request which can be used
to do scripted downloads.
lynx is another good option. i used to use this in scripts until i
> I think this script is *very* important to us, and we should do our
> damndest to make it work well.
i'm glad people think it is so useful. i've used it many times now (and
helped several people on #debian irc channel use it) and it basically
works....a bit rough around the edges and not really suitable for
novices but the guts of it work safely and reliably.
> On a second topic, for those of you still reading, I'm wondering if it
> might not be a good idea to have some for of bail-out script ability
> for upgrades. In other words, the ability to run a script before
> upgrades. This is sort of a vague, of the top of my head idea, but it
> seems that it would be a good way to make sure we can always upgrade
> smoothly, and with the existing frontends. I guess it is sort of a
> hack, and an admission that our tools are not infallible, but I think
> that's already painfully obvious. This would give us a way to
> brute-force any details.
the script would probably not be necessary if dpkg (or any of the dpkg
methods - ftp, mountable, etc) used manoj's pkg-order to sort packages
into dependancy order. both ftp and mountable could be modified to do
this. the default mounted method probably couldn't easily because it
just does a simple recursive 'dpkg -iGROEB'
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
Trouble? e-mail to firstname.lastname@example.org .