Re: dpkg, ELF, upgrade order, broken systems
On Tue, 23 Jan 1996, Fernando Alegre wrote:
> > > I would prefer to have an "elf-update.deb" package whose content
> > > would be:
> >
> > That would probably be a pain to make, unless it only contains the
> > .deb files. and in the postinst, it re-runs dpkg or something.
>
> That's exactly what I am proposing. The file "elf-update.deb" would
> contain only .deb files:
> /tmp/libc5.deb
> /tmp/ld.so.deb
> /tmp/image.deb
> ...
This, to me, sounds like the ideal way to manage the ELF upgrade.
Without a scheme like this, lots of people are going to have major
problems trying to upgrade it themselves. A one or two step procedure
will simplify matters greatly and avoid millions of complaint messages
on debian-user ...
Without a simple upgrade mechanism like this we can all count on getting
a LOT of messages along the lines of "HELP: I just upgraded to ELF and
didn't bother following the instructions and now my system doesn't work!
What's wrong???"
> Then a postinst script would in fact re-run dpkg. This might require
> some change in dpkg to allow two instances to be running at the same
> time as long as they are working on unrelated packages. Another
> solution might be that "elf-update.deb" is empty, except for the
> postinst script. If it has a
If it's too much trouble to patch dpkg to do this, it might be simpler to
have a 2 (or 3) step uprade to ELF procedure.
1. use dpkg to install elf-update.deb
this installs the /tmp/*.deb files mentioned above AND
also a /usr/local/sbin/update-elf script
2. run /usr/local/sbin/update-elf
this runs dpkg on the /tmp/*.deb files which were just installed.
It does so in the correct order.
3. (optional step) use dpkg --purge to remove the elf-update package.
this cleans up the /tmp/*.deb files and gets rid of the
/usr/local/sbin/update-elf script.
Alternatively, step 3. could be made to be the final command in the
/usr/local/sbin/update-elf script (with "exec dkpg --purge .....").
Not sure if step 3 is a good idea or not...it might be useful to make
new packages dependant on update-elf. But probably not, anything
which is dependant on update-elf is probably dependant on libc5 anyway.
The only real reason I can think of for not removing the elf-update
package after it's been run is that it could be useful as a historical
record of when/how the system was updated to ELF.
In favour of purging the package is the fact that /tmp gets cleaned out
regularly, though, which would leave users with a system which had a
package installed but the files missing...won't cause any problems but
will be aesthetically unpleasing.
Just to put my comments in context: I'm running a.out 0.93r6 at the
moment. I've been waiting on some sort of elf update package like this
to make the move to ELF & 1.0/1.1.
> I think this is much more customizable than adding a field. It
> will deal with unforeseen problems much better. I don't think is
> shortsighted at all. All the contrary, adding a field each time there
> is a problem is much shortsighted. The number of fields should be kept
> to a minimum. There is a better way to deal with this kind of problem:
> installation scripts.
my $0.02 worth: agreed completely. makes sense to me.
Craig
--
cas@muffin.pronet.com cas@muffin.apana.org.au
* Unix Consulting: Installation, Configuration, & Support. *
* --- Also, contact me if you need your Dos/Win/OS2 LAN connected to --- *
* --- the Internet. --- *
Reply to: