>
>-----Original Message-----
>From: David Douthitt [mailto:[EMAIL PROTECTED]]
>Sent: Friday, March 01, 2002 3:39 AM
>To: LEAF Development
>Subject: Re: [Leaf-devel] Re: Standards and due process :-)
>
[snip]
>
>It sounds almost like you want a "minimal set" of enumerated binaries and
>functions, and then Oxygen would add set X and Dachstein would add set Y.
>
Nope. No. Nein. Niet. Non. :-)
There is NO baseline.
There is one standard: the formation of a package.
The final decision on a configuration always rest with the user and she
expects the tools to do her job.
I have given specific and realistic examples of how and why the user may
want to float the baseline of a specific distribution, be it Oxygen or
anything else. If somebody else is already implementing these examples then
we should understand that our users will want to be able to do the same.
Last but not least, I have used persistent storage as an example where NO
code from the "distribution" runs before /sbin/init, the point where I
assume the user or some other package will take control. This is the absence
of a feature set and you can't possibly get any lower than this. Again, in
the example of persistent storage, the user will use from the "distribution"
whatever has value to her, be it the menu system or the package management
software apkg.
The existence of this one standard does in no way reflect on anybody's
premises. It does reflect on the user's ability to use arbitrary packages
with arbitraty distributions.
My loading code implements only two rules: a) if a package intends to store
anything in var/lib/lrpkg, the file must be named
var/lib/lrpkg/<package>.{anything.goes} b) file names of the form
var/lib/lrpkg/<package>.{anything.goes.}links are restricted.
If a package does not satisfy these two rules, the package is skipped. Let
the user sort out the issue.
The exact feature set of a distribution is obtained by the unambiguous
enumeration of its packaging. In the example that I have given, the contents
of the initial ramdisk has a feature set (whatever that is) that is
augmented by the feature set of other packages.
If you choose to split this feature set across multiple packages, you still
have the same feature set with the added "feature" of being able to delete
or replace some components in the form of other packages. Spliting the
feature set in 3, 10 or 27 packages does not change the attributes of the
package concept.
Please note that the unambiguous enumeration of the packaging answers
significant parts of questions like "Which distribution should I use?" and
"Will this <fill in package name> work with <fill in distribution name>?".
This is the basis of LEAF: uneducated users and gurus alike should find
something of value here.
I also note that you gave more importance to packaging than to the
fundamental difference between our respective set of promises. However, here
lies a richness that should be exploited. In particular, it addresses
Michael's quest by explicitly stating that name space conflicts are to be
solved by the user. As long as he follows sound practices (like reflecting
installations in full blown systems), Michael's packages should work with
ANY "distribution". In case of doubt, the user decides.
Regards,
Serge Caron
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
