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

Re: Upgrade report from "bo" to "hamm" :-(



-----BEGIN PGP SIGNED MESSAGE-----

On 29 Jun 1998, Adam P. Harris wrote:

> Dan Jacobowitz <drow@false.org> writes:
> > Which reminds me - the same method that we come up with to fix this, if
> > it can be fixed, might be usable for iamerican/ibritish.  What we need
> > is something along the line of what update-menus does but interactive. 
> > Perhaps DPKG:TNG wil include some way of registering a script to run at
> > the end of the configuration?  Any interactive but non-vital
> > configurations could then happen at the very end, easing one point.  It
> > would probably allow one running of inittex and one selection of ispell
> > dictionaries.
> 
> I've considered this quite a bit. It would be nice to have a set of
> well-known, lengthy, oft-repeated installation step (inittex,
> update-menus, and I guess the dictionary stuff comes to mind).
> Package maintainer scripts could indicate they want these processes
> run.
> 
> This would be a welcome addition to the system.  We'd just need to
> find a way to have dpkg trip off these scripts at the end of a run.
> We can't rely on apt to do this, since people will still be using
> dpkg, dftp, or dselect for a long time now.
> 
How about this: a program that, for commands that need to be run for
several packages (e.g. initex, ldconfig [will it work with ldconfig? it
seems risky to me - perhaps lib packages should include their symlinks
to speed up the process]) could be called with the commandline of the
program requested.
	If there was a command with identical commandline, it would not
add a command but discard it and leave the queue as is.
	at the end of the installation process, apt could call
install-queue-run (or similar) to process all of the necessary
post-configuration issues.

	I have one more quip with the system. ldconfig is run EVERY time a
new package with libraries goes in. When you are installing 300+ packages,
1/2 of themcontaining libraries, this adds up. ldconfig is not instant.
	What I suggest is that all of this be implemented in APT and not
dpkg for this reason. 1st: when apt orders the packages for
dependencies, it makes several calls to dpkg. In this case, if dpkg were
the one adding to the queue, it would only know about the current run and
might run long procedures more than once, unnecessarily.
	second, when apt does its install/setup loop for depends,
everything required by the current loop has always been correctly
installed in a previous loop. all libraries, etc. are up to date. So, if
apt were to run ldconfig at the end of each iteration (rather than at the
end of each package's install script) things would speed up considerably.

	I am CC'ing this to culus right now as well.
cheers

- ----
 Aaron Van Couwenberghe -- vanco@sonic.net
 

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv

iQCVAwUBNZkk5foZ48BBEZCJAQFRnwP8DStS0m0yg+5UdLUNvD/FstmAJmXMrxdH
4zX04GQFjVXLNCWzYusM5J02mf7uD5Y7t93fJS9kiuuDFpW2RDySON8lpFv6prCs
4O+jr1Vi3wkAabV0ux32n60jJkz4bipIt+BJD+NfBdxdCLDZLpX+othRxd0CveYk
vLITdYy2bSo=
=qGDC
-----END PGP SIGNATURE-----


--  
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Reply to: