2008/5/25 Peter Tribble <[EMAIL PROTECTED]>: > On Sun, May 25, 2008 at 4:30 PM, Shawn Walker <[EMAIL PROTECTED]> wrote: >> 2008/5/25 Peter Tribble <[EMAIL PROTECTED]>: >> >>> Are they equivalent? I would expect them to be different - I would (at >>> the very least) expect the opensolaris.org one to deliver its bits into >>> /usr, and the blastwave one to deliver into /opt/csw. >>> >>> And if I published my own ant package, it would (and very deliberately >>> so) deliver its bits somewhere different from the one from my OS vendor. >> >> Actually, I believe the intent here is that everything really does >> deliver its bits into the same place. > > Surely not. That way madness lies.
Yet, there is a method to the madness. Most users, that I know of, despise that blastwave delivers into /opt/csw and doesn't integrate into the system. I can't count how many times I've seen posts from users that, once they find out /opt/csw is really its own complete stack, have no interest in using it. Don't get me wrong; blastwave serves an important group of users. However, I think that group is much smaller than the "average desktop user." No one wants to download all of GNOME again, etc. when they already have it. They just want a single component or two. >> As the person installing the packages, if you want them to install >> into /opt/csw instead, you would just do: >> >> pkg image-create -F -a authname=http://blastwave.org /opt/csw >> >> Then: >> >> pkg -R /opt/csw install ant >> >> As such, there's really no reason for the bits to deliver themselves >> into /opt/csw, etc. > > The two cases aren't the same - the root is a different concept to the > install prefix. > > And if I simply wanted to install to an alternate image, I could > do it from the primary authority - I wouldn't have to go to a > separate source of the packages to do it. Yes, that's true. But my comment was in regards to your desire to have it delivered into /opt/csw. >> Some administrators are going to prefer having the isolated stack; but >> many users, I suspect, are going to want any packages they install to >> "integrate" with the rest of the system instead of living in an >> "isolated tree." > > I expect the integrated packages to actually be integrated, and > therefore to come from the same trusted authority. The last thing > you want is a package from some other source delivering bits that > are assumed to be part of an integrated whole. Maybe that isn't what the packager wants, but that could be exactly what the user wants. > If packages from two sources really are equivalent, then why bother > having the second one at all? It all depends on how you define equivalence. First example, Sun might distribute a version of Apache that is compiled with conservative compiler optimisations. A third party might decide to provide an alternative Apache package that only differs in the compiler optimisation options that were used. Are they equivalent in functionality and behaviour? Very likely. Second example, Sun might distribute Rhythmbox, Totem or another program such that it isn't configured so that you can add wmv or blu-ray playback support. A third party might decide to provide an alternative package that is compiled with such options. > And even if they are equivalent then there's no need for the unqualified > names to be the same. (What you do need is for the primary to certify > that a particular exact package from elsewhere is equivalent.) There is no reason for them to be different either, unless you want them to be different. The point is that packages should be interchangeable if the user so desires it. Yes, two packages named the same may not be wholly equivalent on a technical level, but for the user's purposes, they may be. -- Shawn Walker "To err is human -- and to blame it on a computer is even more so." - Robert Orben _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
