On Wed, Jan 27, 1999 at 08:43:30PM -0500, Branden Robinson wrote:
> > * "There should be some better way".
> >
> > Fine. Which one?
>
> Is there a way to have a dpkg --set-selections call lurk in the background
> until the current dpkg process ends, like update-menus does now? That
> would be a far cleaner solution.
Sure, why not do it in exactly the way update-menus does? I think it just
looks for a lock file in some directory or another.
> while (dpkg running)
> wait
Good...
> for oldpackage in xfntbase xfnt75 xfnt100 ... xslib xslibg; do
> case $oldpackage in
> xfntbase) newpackage=xfonts-base ;;
> ...
> xslibg) newpackage=xlib6g-static ;;
> esac
> echo "$newpackage install" | dpkg --set-selections
> done
Be careful! This way, you're forcing all of the above packages to be
installed, which you could just as easily have done with a dependency by
the dummy xbase.
oldpackages="$(dpkg --get-selections
| egrep '^(xfntbase|xfnt75|...)'
| awk '{print $1}')"
for oldpackage in $oldpackages; do
[ "$oldpackage" = "xfntbase" ] && echo "xfonts-base install"
...
done | dpkg --set-selections
Every invocation of dpkg is horribly slow, so we should try to limit it to
one call each of get-selections and set-selections. The above should do the
job, but it's untested so there are probably syntax or logical errors.
> The second half is easy. Waiting for dpkg to finish is what I don't know
> how to do. There is also the issue of guaranteeing that apt(?) is invoked
> to realize the state of the new selections.
Hmm, I don't think that's necessary; apt only seems to cache _available_
packages, not user selections, I think.
Besides, if dselect/apt don't notice the preference changes immediately,
it's still okay -- just the "new" packages won't be installed until next
time dselect/apt are run. Big deal. As we know, the old packages aren't
hurting anything anyway.
Now, on with the flamewar! Don't let me stand in your way.
Have fun,
Avery
