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
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
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.
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.
---
.je
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
