> when I want to install libbonobo as a dependency for > another package, I want just that and one copy on my > system, and let every package that needs it find it. > company ticker appended to package names is one > ridiculous idea, when a simple package name would do > just fine. All, pkg-get would check for is if > libbonobo is installed not if CSWlibbonobo is > installed. If the --libs, --cflags, --prefix are > exposed correctly and paths/crle are handled > correctly, then no matter where the packages are > installed, they will just find each other.
That's why I keep coming back to pointing out that SGI already has this whole problem pegged. In fact, SGI has implemented a solution to this problem in IRIX so elegantly, that it is mind blowing. This is what makes their `inst` subsystem light years ahead of any package management subsystem out there... and `inst` is, what? 10+ years old? Let me give you an example. SGI has an online repository like Blastwave, called SGI Freeware at http://freeware.sgi.com/ Now, let's say you install OpenSSH from their repository, for the sake of getting the concept across, version 1.0. When `inst` fetches the package, you will get openssh-1.0.tardist `inst` then untars the actual [I]package infrastructure[/I] into a temporary directory, and loads up the binary package descriptions from there. You end up with a tree view, like this: eoe.swopenssh eoe.sw.openssh.sw ... ... ... eoe.sw.openssh.libs ... ... eoe.man.openssh eoe.conf.openssh.etc So, it's kind of like an HP-UX depot in the sense that there are software subsystems contained within the what SGI calls a "dist". BTW, "eoe" stands for "execution only environment", SGI's term for a binary only package. Now you get to just pick the entire eoe.sw.openssh dist, ("install") or just certain components, for example, I may want eoe.sw.openssh.sw and eoe.sw.openssh.libs, but [I]not[/I] the man pages eoe.man.openssh subsystem ("keep" in SGI terminology). Run time dependencies are resolved when the admin types in "conflicts" or when he types in "go" (install the software selections). Here is the point I'm trying to make: An admin installs SGI's OpenSSH V1.0, [I]eoe.sw.openssh[/I] (notice the absence of version? It's the intelligent design of `inst`, but we'll revisit that later). Lets say that I now want to install OpenSSH V2.0. What I do is create my own [I]eoe.sw.openssh[/I], and if I'm just [I]careful enough[/I], I'll increase the dist's [I]internal serial number[/I] by 1, in fact, `swpkg` will do this for me [I]automatically[/I] every build iteration. All I have to do is set the initial [I]internal serial number[/I]. When SGI packages OpenSSH V2.1a38g, the `inst` subsystem sees my [I]eoe.sw.openssh[/I], sees that the [I]internal serial number[I] is in the [I]SGI serial number range[/I], and automatically replaces my version of OpenSSH subsystem! See the elegance at work? The idea is that SGI will [I]always compile and package better than myself, since they know IRIX best and know better than I what they're doing[/I]. Later down the road, should I wish to instal OpenSSH 2.5, all I have to do is [I]reuse[/I] my dist definitions, copy the [I]internal serial number[/I] of SGI's OpenSSH into my template(s) and increase it by one, and `inst` will replace [I]eoe.sw.openssh.* subsystems[/I] that I specify (every subsystem within [I]eoe.sw.openssh[/I] has its own serial number). This way, I could, for example, only [I]update eoe.man.openssh[/I] and leave the rest of SGI's OpenSSH [I]intact[/I]. I hope I've given some insight into how well designed and how intelligent this stuff is. I'm really sorry that I don't actually do `inst` justice in these examples. This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list [email protected]
