[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New package managment
On 23-Sep-99 email@example.com wrote:
> I see a couple of gaps to fill into autoconf/automake. I'm sure
> someone will comment I'm misguided.
the end user should see "./configure && make all install". for what
autoconf/automake/aclocal/make does, that's remarkable abstraction. :) For the
person making the .in and .am files, it can be tricky, tho :)
> 1) You could add packaging hints to autoconf/automake so that RPM spec
> files and whatever DEB's use would be automatically generated as part of
> the configure, make process.
> 2) You could write some sort of meta-RPM package search engine.
> (although rpmfind does some of this) Debian packages (I've gathered)
> can search out and download their dependencies.
debian packages understand they need a certain package at a certain version.
They make the request to fulfill this requirement to the package program (apt
or dselect) which in turn checks its database for one that fulfills that
requirement. Then dselect or apt will ask if you want to meet those
dependancies or abort. very nice imho :)
> That said, if you have your heart set on remaking a packager from the
> ground up, I've been mulling over what it would take to flatten the
> complexity of the whole configure; make; package; install; process into
> one (or a few) XML dtd's. if the XML specified a few basic items
> 1) environment tests (configure tests..)
> 2) build dependencies -- local and external
> 3) installation directions
> you could support a gradual switch over from the current systems by
> writing conversion utilities that would go from a bld-pkg-XML spec to
> configure make, RPM, DEB...whatever.
> BTW. I think that to get the most universal usage out of a new
> build-package system it would need some way of keeping distribution
> specific configurations as well as architecture dependent packaging
> configurations separately. It would also be nice to have a method of
> combining partial specs into larger specs. Ie one person does the i386
> redhat config someone else takes that and adds i386-debian install
> details, etc.
interoperability with the native package format is critical, imho. How will the
game know if I have mesa installed? how will the native database know if I have
such&such lib installed if I installed it with the differnet packaging system?
Package management tends to be an install-time commitment... :)
> Of course, its easier to speculate than code...
> Alan Chen
> Aerospace Simulation Engineer and Recovering Linux Newbie
> Now Running: Redhat 6.0 + Tweaks
-Erik <firstname.lastname@example.org> [http://math.smsu.edu/~br0ke]
The opinions expressed by me are not necessarily opinions. In all
probability, they are random rambling, and to be ignored. Failure to ignore
may result in severe boredom or confusion. Shake well before opening. Keep