[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


  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: