On 5/7/07, Steven Stallion <sstallion at gmail.com> wrote: > Peter Tribble wrote: > > On 5/7/07, Steven Stallion <sstallion at gmail.com> wrote: > >> Everyone, > >> > >> I have completed the draft proposal for the Open Package Management > >> project (previously known as ports). This document details the research > >> and analysis that has been done to augment Solaris packaging to provide > >> a more consistent feel towards handling third party software. I would > >> like to see this document used as a basis for the delivery method for > >> this new project. > >> > >> You can view it here: http://docs.google.com/View?docid=dhbvzvv7_0f9prct ... > A good example could be that sun provides a repository for SFW, and > blastwave provides a repository for its own packages. OPM essentially > bridges the gap between disparate repositories.
I think that's actually where the complexity - and difficulty - enters. We know how to do this with a single repository - blastwave does the job already. If having multiple repositories is what OPM is about (and it seems to be one of its core concepts) then we need to work out what the rules for interaction and arbitration between different repositories are. > > You identify package repositories by a URL. However, a URL refers to > > a particular instance of a given repository. How would I refer to a local > > mirror, when the system needs to know that this is really just a different > > path to the same repository? > > This is a case where the transport can shield the user from over > complicated configuration. A good example is using a load balancer URL > to provide applications. Or, more simply, just define your repository as > pointing to a specific mirror. Not really; a load balancer isn't going to help me get the UK or Australian mirror as appropriate. You need to separate the logical name of the repository (what it delivers) from the implementation detail of how to get to an instance of it. > > Why separate repositories for i386 and amd64? We've largely eliminated > > the separate packaging for these. > > This was more for illustrative purposes. I am not as familiar with how > 32bit vs. 64bit packages operate today on Solaris. If it is unnecessary, > then by all means, lets remove it. However, I think that it is important > to provide 64bit packages, especially to amd64 users due to the > performance gain. Indeed - which is why Solaris dispenses with the idea that 64-bit is separate. Packages deliver both 32-bit and 64-bit; if something can be both (libraries will be, many commands won't need to be) then both are delivered in a single package so you always get the 64-bit files installed. > > I'm not sure abbreviated package addressing is desirable, unless you have > > a central authority responsible for doling out the package names to ensure > > that ambiguity can never arise in the future. > > The authority lies within the repository. A repository controls the > naming of everything within it. But what about naming within other repositories? > > My reading is that a package has both the new name and the old traditional > > name. Is that right? Won't having multiple names for the same package > > lead to confusion? > > Yes and no. The old name is the canonical name of the package. However, > the name itself gives no type of hierarchy to the package. Given the > SUNWsndmr package, it is impossible to tell what category it lies in > (and arguably what it stands for). The snag there is that the package system then only understands the old (canonical) name. So, at initial installation, you use the one name; subsequent interactions use a different name. I'm not at all convinced by the complexity of the naming scheme. Having a traditional package name and the long fmri name is a source of confusion; allowing abbreviated naming (and defining the abbreviation as "whatever matches uniquely") adds additional confusion and the possibility of inconsistency. Besides, I suspect that users just want a fixed abbreviated name - "install kde for me". Putting hierarchy into package names also seems to me to be a bad idea. A package may deliver functionality into multiple functional areas, or may reasonably sit in several different places in the hierarchy. So: a package has a single package name in the traditional manner. (Repository name as prefix, as is common now.) the interface uses fixed abbreviated names, which might map to individual packages or to clusters. categories are simple metadata tags allowing the UI to group or filter the available software. (If these tags live in the pkginfo files then the information is carried through and remembered by the installed packages) > > How do you handle conflicts between different repositories supplying > > different versions of the same pathname? > > OPM deals with revisions much the same way that FreeBSD ports or > darwinports does. There is only a 'current' version. If there are major > release differences (ie: apache 2.0 and 2.2) a different package would > be made (this mirrors how solaris does it today as well). A pkgdb > instance tracks a repository on a given date - which means that version > numbers will always match until a repository update is issued. That's not what I meant. As an example - say two different repositories both supplied packages that gave /usr/lib/libaa.so. Who is responsible for managing this conflict and how? Do we declare that each repository has to live in its own isolated area of the filesystem? (Which is basically how this is handled today.) > > For source built packages, surely what compiler is available on > > the system plays a part in determining which compiler is used? What > > if a required part of the build toolchain is missing - does that get > > installed as a prerequisite? > > With gcc or gnu tools, yes. With SUNWspro, I believe it is out of scope. > I think it is a fair requirement to state that if someone wishes to deal > with source-built packages, SUNWspro and SUNWsprot are required > dependencies. That doesn't seem like it would necessarily work. One advantage of adopting some scheme like OPM is that you can install a relatively small core OS and download the rest on demand. Easy to do with the gnu toolchain, but somewhat harder (possibly from the licensing/distribution issues, and due to the size) of the Studio suite. Mind you, I would like to see the Studio compilers used more widely - I don't see that you could have them as prerequisites. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
