DragonFly kernel List (threaded) for 2004-02
Re: Packaging system effort
Since this was already discussed in another thread some time ago,
I'll try to focus on some of my major concerns.
No citations, no handwaving and no flamewar-attempts involved and intended.
1. Don't put yourselves under pressure because of some June Release Ghost.
Pressure is a helpfull fellow at the right moments to get things going,
but any `release' this year could only be some kind of technology preview.
Exciting new technology, but still a preview.
2. OS-agnosticism is not the right attitude towards an integrated
third-party-software-management-system. It is one of the *goals* of DFly
to provide a superior packaging-system by means of vfs layer abstractions.
So instead of OS-independance I'd opt for dependance on something like
`we need POSIX and we need vfs-environments-api as defined in...'
Maybe Matt could file an RFC or something like this once we know what
is *really* needed ?
After all, real OS advances were driven by the needs of real applications.
3. One of the culprits of a new packaging-system in real life is the way
people can actually *provide* new packages. If you can provide a new
package just by recording the libraries and options you needed to get
it going, like suggested by Matt with vfs environments, that'll give
you much more software available than any whoo-is-that-easy-to-manage-stuff.
So, I'd like to see the vfs stuff as a starting point. The API is not even
formulated yet. But I'd rather focus on the needs of a package-*provider*
for now to formulate them.
Campus der Max-Planck-Institute Tübingen
Netzwerk- und Systemadministration
Tel: +49 7071 601 598
Fax: +49 7071 601 616