johan...@sun.com wrote:
On Tue, Aug 25, 2009 at 12:24:49PM +0100, Peter Tribble wrote:
On Fri, Aug 21, 2009 at 6:38 AM, Shawn Walker<swal...@opensolaris.org> wrote:
Jonathan Edwards wrote:
(5) missing no-deps or force install/remove
This is intentional. The package system can't be expected to manage
broken packages. If we provided a --force or --no-deps option, that
creates a broken package graph, which inherently makes the system
unmanageable. There are no plans to implement that functionality.
That's unfortunate. It's the requirement that the system be manageable
that drives requests for dependency overrides. 15 years of managing
systems and software has demonstrated to me conclusively that you need
to be able to override everything. Administrative tools are supposed
to help administrators, not prevent them doing their job.
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.
But in real world there will always be some packages with incorrect
dependencies and sometimes there will be a need to fix a problem *now*
and only then report it back and wait for a proper solution. By not
providing these options you only making it harder for a sysadmin to fix
an issue at hand - he/she will have to do it regardless if pkg makes it
easier or harder - why not to make his life easier like other packet
managers do on other operating systems?
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.
Really? I thought that one of the goals of Open Solaris is to make it
easy to use for sysadmins and at least on par with other operating
systems. While above solution will fix the issue it is hardly sys-admin
friendly especially compared to linux/rpm where sysadmin would fix the
issue with one command.
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.
There are much more ways for a user to render his system to a
non-supported way and there isn't really much you can do it. By all
means put an information in pkg(5) that by using --nodeps or --force one
can end-up with a system in an unsupported state. Because sysadmin when
faced with an production issue with a broken package will either copy in
binaries manually or create their own package as you suggested and I
would imagine it would render their support contract even more void :)
We're not preventing you from doing your job, we're trying to prevent
you from building a broken default configuration.
Can't agree here.
So again, how am I suppose to fix an issue with a package delivered by
OS with a broken dependency without affecting my support and withing
next 5 minutes? Because if I open a case with Sun (or any other vendor)
in 99.999% of cases it won't be fixed within a week.
What if a package is coming from /contrib? Getting it fixd by a
maintainer could take ages, and I doubt Sun provides or will provide a
support for such packages anyway. Still there
is a good reason why such repository exists and people will use it and
sooner or later will come across a package with broken dependencies and
will need a quick fix. By not providing --nodeps and --force you are not
preventing them from doing their job you are "just" making their work
harder with even worse consequences both for them and from a support
point of view (at least you have the control on how --nodeps would work,
while you have no control at all how a sysadmin will fix an issue
without such feature).
--
Robert Milkowski
http://milek.blogspot.com
_______________________________________________
pkg-discuss mailing list
pkg-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
