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). Is OPM an interface or an implementation, or both? (One way to look at this is to ask how alternative implementations might be built.) 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? 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? Why separate repositories for i386 and amd64? We've largely eliminated the separate packaging for these. 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. 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? 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? How do you handle conflicts between different repositories supplying different versions of the same pathname? 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? What control is offered over dependency resolution and automatic installation of dependencies? 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. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
