On 5/8/07, Peter Tribble <peter.tribble at gmail.com> wrote: > ... > > 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.
Absolutely. Again this is a proposal, nothing set in stone. > > 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. Ahh I see what you meant. That separation is there. When a user selects the repository to use (pkgdb add), he assigns a logical name to a specific mirror. Conventions are to use vendor prefix. For example, lets say you want to add an .au mirror to serve your sunw repository: # pkgdb add sunw http://my.special.repository.au/ Or you wish to use your local .uk reposotiry: # pkgdb add sunw http://my.special.repository.uk/ > 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. Fair enough - I am all for simplicity. pkgbuild will probably need to have an additional flag added to make sure that 32bit compatibility libs are created for each package. > > The authority lies within the repository. A repository controls the > > naming of everything within it. > > But what about naming within other repositories? All we can really offer are guidelines and conventions. One of the unfortunate side effects of an open framework is that implementors have the freedom to ignore it. I think one way this can be curtailed is that we advertise or support repositories which are compliant and offer real use to the community - this will help steer new users away from less desirable repositories if they ever pop up. > > 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. Well, I may not have explained this well enough in the first place. The idea is that the fmri form is a decomposition of the actual package name. For example: SUNWsendmail would decompose to sunw:/category/sendmail. Adding the category is new, and allows for a bit to be easier to find. Take a look at how most ports systems are defined - they each use a file system structure whereas Solaris uses a flat structure. This makes it very difficult to find a given package on the file system. > 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". Which they can do. The fmri form is used for name composition. You get your install KDE. The package name itself is offered for compatibility. For example: pkgget kde pkgget x11-wm/kde pkgget osw:/x11-wm/kde pkgget OSWkde All mean the same thing... > > 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. It is not placed in the name, but the address. The name of the package is the last element in an address. For example, osw:/x11-wm/kde - kde is the package name, osw is the vendor, and x11-wm is the category the package belongs to. > 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) Metadata which is for software to use - not people. Solaris packages are distributed in a flat directory, there is no physical hierarchy. There is no post install software managment that conveniently shows packages according to category. This is normally accomplished by directory hierarchies in a filesystem. This is what ports systems use for categorization. The reason for the fmri hierarchy is the same exact reason why there is a directory structure when organizing service manifests. Flat doesnt work - end of story. > > 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.) The conflict can be resolved by SVR4 packaging. Anytime you attempt to install an overlapping package, you get a warning - this will be no different. We cannot control the number and type of repositories a user may select, but we can control the ones that *we* offer officially, and ensure that there are no conflicts. This can be taken care of with discipline and a little scripting. > > 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. Essentially this is determined by the software and the repository owner. If a repository (most notably SUNW) wishes to use SUNWspro, then they should - and any user who wishes to *build from source* must adhere to that. The complexity of supporting any compiler set is unreasonable. Many GNU bits are notorious for using GCC specific macros and extensions. ---- A few more comments: This project is aimed to provide a framework for sun and others to provide software to a user in a common way. We should not and cannot be in the business of attempting to control the user. The user has to accept some amount of responsibility if they decide to deviate from officially supported repositories. Steve
