On Wed, Aug 26, 2009 at 01:00:14AM +0100, Robert Milkowski wrote: > johan...@sun.com 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. >> > 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?
You're granting me my point implicitly. :) Nobody is stopping you from copying files around or messing up your system, if that's what you want to do. Rather, we're insisting that a package's dependencies are satisfied as part of the installation. The assumption that the packages will always be broken is false too. Part of using pkg(5) in future Solaris products means that Sun can greatly simplify our test and QE matrix. By unifying patching and packaging, and removing dim-sum patching, we gain the ability to more thoroughly test the configurations we release, since the combinations of packages and patches that need to be tested are no longer infinite. Your assuming that installing a package without its dependencies makes life easier somehow, but again, I haven't heard a clear argument for why this is a reasonable thing to do. >> 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. That's the solution if you don't like the currently delivered package boundaries and want to define your own. I'm not suggesting that everyone is going to want to do this; however, sites that want or need their own custom configurations may do this. >> 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. Sure. Nobody is suggesting that we can stop users from messing up the system. Rather, we're trying to make it difficult to do so with package managment. > 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 :) Maybe and maybe not. We have pkg fix, that can restore your system to a known good state. However, if you've overridden the dependency checking, how is the fixer-upper going to know what to repair? >> We're not preventing you from doing your job, we're trying to prevent >> you from building a broken default configuration. > 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. Nobody has been able to clearly articulate what the issue is, so it's hard to speculate about a hypothetical problem. It sounds like most people are nervous because that option isn't there, even though we can't describe scenarios where this might be useful. > 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. I think you have this backwards. If a package comes from /contrib and its dependencies aren't satisfied, you can't install it and break your system. You're asking for the --no-deps option so you can install the broken package and have who knows what happen to your system. -j _______________________________________________ pkg-discuss mailing list pkg-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
