Ralf S. Engelschall wrote:
On Thu, Nov 02, 2006, David M. Fetter wrote:
I notice that the latest 2-STABLE-20061018 release is now including the
EVAL src.rpms. In addition, it seems that there are inter-dependencies
between CORE, BASE, PLUS and EVAL which don't particularly leave me with
a good fuzzy feeling. My suggestion is that CORE and BASE should not
have any dependencies on software outside of themselves. The logical
reason is that by having dependencies outside of CORE and BASE, which
are the assured production quality software, it taints that assurance
with software from any other source. Ultimately, all software that is
assured production quality should also have the same assurance for any
dependencies that software may have. The functional reason is that it
would be nice to simply exclude the PLUS and/or EVAL sub-directories
from custom build repositories without having any missing dependencies.
This would ease things if a customer/user just wants to install
production quality software only and non of the PLUS or EVAL software.
Also, in a similar mindset, nothing from PLUS should have dependencies
on anything in EVAL but the reverse can certainly be true. Thus, PLUS
could have dependencies from software within CORE or BASE but not from
EVAL. EVAL, of course, could pretty much have dependencies wherever
since it is for evaluation only. Anyway, I thought I would send this
suggestion out.
Well, the classes _are_ full subsets of each other and without any
dependency errors _WHEN IT COMES TO THE DEFAULT BUILD OPTIONS_. It
is correct that there _are_ options which then cause additional
dependencies to be activated which in turn break the class embedding
order. That's the price of this flexibility.
But unfortuntely this cannot be resolved in mostly all of the remaining
cases known to us because usually the dependend package usually does
_NOT_ qualify for the higher quality class of the package it requires
it. For us it is more important that the class of a package describes
as best as it can the package's "content quality" (the vendor software
it contains) and not primarily a totally stricly independent set of
packages within the distribution.
If you followed the release engineering processes you have seen
that we are very carefully in blessing packages for higher classes
and especially in the last release engineering process we even were
forced to downgrade a bunch of packages to lower classes to fix some
classification problems.
With over thousand packages this whole package classification is already
extremely difficult and it is obvious that one cannot make it completely
perfect from all points of view. Currently it is nearly optimal from the
content classification and default-option based dependency order. To be
both optimal from the content classification and total dependency order
is IMHO not possible. For this OpenPKG is already too flexible with its
build options.
BTW, the reason why we now finally decided to also include the EVAL
packages into the snapshot distribution is because many people asked for
this in the past (mainly to have a more self-consistent distribution at
hand and not requiring mixing of distributions).
All of this is understandable to me, however, I made the suggested
because it comes down to simplicity. Most "customers" want things quick
& easy. So, if you want to grab a decent sized customer base real
quick, then making it as easy as possible for them will be important.
In conjunction with "quick & easy", the "customer" also wants stability.
While many folks may desire to have EVAL included, it takes away from
a certain stability. Now, I haven't had the time to take a deeper look
at the E1 release, so maybe it is more along these lines already.
Basically, in my experience with consulting, customers want a couple
main things: "Quick & Easy"; and, "Stable". I'm taking some extra time
to go through the process of building everything and I'm just taking
down some notes that I think might be helpful to make OpenPKG even
better than the spectacular product it already is.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
The OpenPKG Project www.openpkg.org
Developer Communication List openpkg-dev@openpkg.org
--
David
"Beware the barrenness of a busy life." ~Socrates
______________________________________________________________________
The OpenPKG Project www.openpkg.org
Developer Communication List openpkg-dev@openpkg.org
