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).
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
The OpenPKG Project www.openpkg.org
Developer Communication List openpkg-dev@openpkg.org
