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 >> >> Please comment - there is a lot to talk about :) > > Questions more than comments: > > When you say that OPM complements the SVR4 packaging tools, how does > it relate to them? Does it sit alongside, or is it a layer on top > (like pkg-get is).
It would be a layer on top (similar to pkg-get). OPM would be a consumer of SVR4. > > Is OPM an interface or an implementation, or both? (One way to look at > this is to ask how alternative implementations might be built.) Its not quite that well defined. The OPM is really just the runtime provided to access repositories. Repositories must be implemented in specific ways, but for the most part, that is where your alternate implementations would live. 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. > > If software had been managed with OPM tools, and then subsequently > managed solely with SVR4 packaging tools, would there be any > possibility of corruption of the system? Ideally, no. This still remains to be discussed and specified, but since the result of any action that OPM takes results in a call to SVR4, i think this could be reasonably done. > 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. > 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. > > 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. Abbreviated names are a relatively new feature with ports type systems, and they have been very well received. It reduces the need for searching for a specific category, or looking for a specific vendor prefix. > 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). > Do you mean packages or clusters? For example, assuming I want to > install sendmail then does asking for sendmail get me a sendmail > package, or the whole cluster of sendmail packages, or a virtual > package that ensures that all the sendmail packages get installed > via dependency resolution? Most ports systems do not have the concept of a cluster for a specific piece of software. If you install sendmail, then you get all of sendmail. OPM is intended to function the same way. Having packages broken into several bits causes unnecessary pain dealing with dependencies. Remember, OPM is limited to third party software only. > 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. > 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. > What control is offered over dependency resolution and automatic > installation of dependencies? Whatever is deemed needed. This is just a concept document and is by no means an exhaustive specification. > You say that duplicate package installation should be avoided at all > costs, but one of the things that I'm finding increasingly essential is > the need to support multiple versions of the same software, so that > multiple versions need to be supported as first-class citizens. Multiple minor releases are near impossible to support outside of library dependencies. Essentially, if there is a revision that is not backwards compatible, a new package must be created. This is how both Solaris and other ports distributions handle the incompatibles. Steve
