Jonathan Edwards wrote:
On Aug 25, 2009, at 4:36 PM, [email protected] wrote:
The system has to be servicable in addition to being manageable. After
reading the posts in this discussion, nobody in favor or no-deps or
force has been able to articulate why this would be necessary if
dependencies are kept correctly in package metadata.
it's this exact assumption that's being challenged, and i think the
response essentially boils down to "not our problem - the package
creators need to 'correctly' structure and define their dependencies" -
(whatever this means) .. or "file a bug if a package dependency is
'broken'" - (for whatever we take the term broken to mean)
the only problem i am trying to highlight is that there is little
recourse for action for the administrator who may have more knowledge of
the proper package dependencies than the package creator
And we're perfectly happy to provide tools for managing that *separate*
from the pkg client itself. If we made it easy for users to copy an
existing package and strip out all of the dependencies (think something
like pkgrecv --no-deps ;)) then administrators still have a recourse for
action and the pkg(5) system doesn't have to attempt to manage a broken
package.
Instead of trying to sledgehammer the aspects of the package management,
think about how you would like to manipulate, split, or alter existing
packages and then propose a new tool or options to an existing tool to
do so. That is a far more supportable path.
There's nothing stopping administrators from taking our packages using
pkgrecv(1), modifying the contents to remove the dependencies that they
don't want, and then sending the package to their own custom repository.
Just don't call us asking for support when things break.
ok .. agreed - but supportability should realistically revolve around
certain core component variation in a system - and i would argue that
the core component structure we submit as "supportable" is still a
relatively large bundle.
i find this line of reasoning similar to the problems we had with
supportable minimization in SVR4, and the pundits who continually held
that the only properly supportable system involved a minimal install of
the SUNWCall metacluster
Package boundaries are being changed and have already been changed with
the introduction of the OpenSolaris 200x releases. I do not believe you
will encounter the same resistance to a better core, supportable
approach with these releases. The requirement of fitting the base
system on a single CD has already forced several changes and fixes to
boundaries.
It's easier to add support for no-deps later, if we ever encounter
a case that really requires it, than it is to ship a packaging system
that lets users build a broken system out of the box. If we ever did
support a no-deps option, it would likely render your support contract
void on use. There's just no way we can service a configuration that's
not deterministically constructed.
i totally understand the desire to prevent abuse of the packaging system
(as is frequently done) .. i think we're just saying that without
options similar to these the only path an administrator can take to
install is the road that's set before them - with no shortcuts or
workarounds in the mix. If supportability is really a concern if this
sort of thing was worked around - then perhaps we should really be
applying the "tainted:P" approach if anyone takes an install path that's
not correctly defined.
My preference would be to provide tools to make it easier for
administrators to customise existing packages and then place them into a
'custom package repository' that they could then use. Customisation
during publication is easily supportable, while customisation at runtime
across various upgrades, etc. is not.
We're not preventing you from doing your job, we're trying to prevent
you from building a broken default configuration.
we're all after the same goal .. i just don't think that limiting choice
is the proper way to get there, particularly for people who may want to
use some of the tools and packages, but not all of them that we deem to
be the only properly supported ones.
Resources are finite, and so we are focused on the functionality that
gets us to a supportable system. --no-deps and --force option for the
pkg clients are an unnecessary distraction and detriment to those goals.
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
