(One last item for today.) As with the tags and attributes thread, I've summarized the main issues for the mail thread, with responses. Based on these, plus any further comments, I'll update the materials accordingly.
Beyond the thread in pkg-discuss, you should also read Mike G's blog entry http://mgerdts.blogspot.com/2008/03/solaris-wish-list-feature-based-meta.html and his diffs to the previous version, at http://cr.opensolaris.org/~mgerdts/pkg-names-and-groups/ I suppose I either providing work reading or vacation reading, depending on your weekend plans. - Stephen --- 0. Terms. Mike's edits reorganized the definitions a bit and improved them. Ultimately, these will need to move to a glossary, and into manual page form for the pkg(5) page as well. 1. Safe namespace. By a safe namespace, I mean developing a set of conventions that make it easy to (a) claim a package FMRI and (b) assess the likelihood of collision on that FMRI. For instance, in System V packaging, this safety was done by using NYSE/AMEX/NASDAQ stock symbols as prefixes, plus some special, nominally registered other prefixes. (And this pattern, beyond the implicit barrier presented to smaller package publishers, isn't safe in this sense: CSW is Canada Southern Petroleum, FOX is Fiber Optic Systems Technology Inc, SFE is Safeguard Scientifics, Inc., SMC is Central Sun Mining Inc., ...and SUNW is up for grabs, I guess.) 2. FMRI vs categorization/classification. The FMRI is the package identifier. A full one uniquely specifies a package; a partial one specifies a set of matching packages in a deterministic fashion. Categories, classifications, and descriptive summaries don't have these properties. I'm fine with multiple classification schemes, but we must have unique identifiers. I don't believe that FMRI stability should be reserved only to higher level groupings or renamings of packages. I also wouldn't agree that staying with a flat namespace for package FMRIs makes the system easier to use--I guess I think smf(5)'s use of FMRIs and abbreviations is easy to use. Perhaps not? 3. Equivalency. Peter T asked "Are you saying that you expect any two packages with the same unqualified name to be interchangeable?" Yes, this is the restriction; it allows a system to have a mix of sufficiently equivalent components from multiple publishers. Luckily, Mike G give us an example question to work through: Suppose apache.org published the exact same ant release as: pkg://opensolaris.org/vendor/apache.org/ant pkg://blastwave.org/vendor/apache.org/ant pkg://apache.org/devtools/ant Is there any way to for a consumer system to understand that they are equivalent for the purpose of dependency mapping? In the scheme we're proposing, the first two would be equivalent--and expected to deliver components to the same location. The third would not be, because "devtools/ant" and "ant" aren't the same. (See vendor/ namespace below.) (That's not really what Mike was asking, though. The question of how best to express dependencies is still open; my preference is virtual packages, but Bart and Danek make arguments for "compiling" capabilities.) 4. Forward domain names in authorities. I would prefer to keep forward domain names in the authority section, to make automatic discovery meaningful and straightforward when no configuration for an authority is known. The mirroring or substitution of actual HTTP URLs is already handled by having an explicit configuration; the -O option to pkg set-authority already allows this kind of substitution. I believe that this format would mean that the comma-form for proxy publishing in Mike's edits would be disallowed (bottom of 2.2). 5. Reverse domain names in package names to match our (new) tag/attribute convention. 6. "Fragment identifiers". Since we have pkg://authority/[EMAIL PROTECTED] as a well defined pattern (since @ is not permitted in pkg_name), we could do any or all of pkg://authority/[EMAIL PROTECTED]/extension pkg://authority/[EMAIL PROTECTED]:specifier pkg://authority/[EMAIL PROTECTED] or even pkg://authority/[EMAIL PROTECTED]/extension:specifier#fragment to enable access to specific resources within a package. As I mentioned, we did this for smf(5), but it doesn't get used much, so probably best to just reserve these patterns and move on. 7. Optional version? The user interface is able to calculate a likely specific version of a package, so it's optional in the sense that pkg://authority/pkg_name can be consistently interpreted to mean something. 8. "Group packages", "incorporations". Group packages and incorporations aren't different in terms of the mechanism; it's more that these types of packages are interesting for trying to assemble larger chunks of software and seem to be worth distinguishing. I think Mike's point in 2.4.2--that developer bundles should be group packages that pull together a set of packages larger than needed for that component's use on a non-development system--is a good means of giving two angles into the namespace. 9. Comma prefix escape. This syntax is in PSARC/2002/547 "Greenline", which I was just making sure I could rebuild the other week. The example I gave initially now reduces to pkg://opensolaris.org/.../com.example/whiskers pkg://opensolaris.org/.../com.example,whiskers which are different. In the latter case, example.com is only expecting to publish one package in whatever category/subcategory we elided with "...". In the former case, we are expecting multiple packages. The advantages of the ',' escape is that the probability of collision in abbreviation matching goes to zero. 10. The site/ namespace. Reserving the site/ portion of the namespace makes it easy to issue organizationally-private packages. site/ packages should not appear on public authorities, but use of site/ is otherwise left to organizations. I would expect large organizations that share software internally to construct multiple internal authorities, so site/ is only likely to be useful to small groups or individuals. OpenSolaris projects will never publish within the site/ namespace. (I guess I should confess that I try to be cautious about releasing namespace--once let go, you can never get it back.) 11. That vendor sentence. and the vendor/ namespace. The incomplete sentence was The top-level "vendor" category is reserved for use by organizations providing additional. This thought was supposed to be for the case where one produces pkg(5) packages but hands them to some other distributor to publish, or even to more than one such distributor. I think this scenario is primarily of interest on the commercial side, but it's still pretty likely: managing identities and entitlements and paying for bandwidth isn't going to be interesting to all software vendors. So the sentence should read The top-level "vendor" category is reserved for use by organizations providing access to additional packages from other publishers, separate from those packages provided by the organization itself. Dan's example: Some examples of what would and would-not be a vendor would help. I wasn't sure if the following would go into "vendor", or not? - Sun "add on products? - Open Source Projects not affiliated with the OpenSolaris community? - Software which requires the user to acquire a paper license to run? It's none of these really. Each of those can live under a normal FMRI; the paper license case should be handled by having a separate authority/repository where licensing is handled prior to the package operation. It's much more that ACME Co. wants XYZ Inc. to distribute ACME software from their site, so that ACME either doesn't have to run its own depot or that ACME's software gets exposed to XYZ's catalog subscribers. So pkg://xyz.com/vendor/com.acme/coolapp and all its metadata shows up in a listing of xyz.com's catalog. One question this scenario leads to is whether there's a benefit to having a mapping from //auth/vendor/reversed-vendor-auth/pkg to //forward-vendor-auth/pkg. such that the equivalence mentioned in #3 above can be asserted. Having such a relationship means that, as vendors move in and out of various decisions that affect the lifecycle of the underlying component, the dependency calculations remain relatively stable. 12. The feature/ namespace. Mike G's blog entry primarily proposes top-level feature/ namespace to collect "features". It's a good post: I agree with most of the aspects it raises, except for the premise that a single feature/ namespace is required to address them. The problem of FMRI categorization presents itself with or without a grouping namespace; the labelling of packages with a stability attribute (info.stability) is required whether or not a grouping namespace also exists. We have to tackle these no matter what. I think there's a deeper process aspect: should initial package providers attempt to categorize their packages at all, or should this always be deferred to some distribution-level body? The feature/ namespace appears to require the latter. I guess I still hope that a system can be sensibly composed from multiple authorities, without going through this step. (I should also note that we tried the rfc path on one of the smf(5) printing services, and received pretty negative feedback. That's only anecdotal.) That said, the bundle-style packages (like amp-dev in 2008.05) need either a top-level category or need a naming convention or attribute that makes them easy to find. (There will be bundles for audiences other than developers, so "*-dev" isn't the convention we're looking for...) 13. Rotated namespace. The idea behind rotating the namespace was to make it easier for users to find packages of interest--which are likely to be applications. Of course, the rotation doesn't reduce the number of packages in an "all" listing. Danek is right to point out that the FMRI abbreviation matching makes it easy to keep typing to a minimum. So perhaps we're actually looking for a tag that says "suppress this package--it's just details". Both the rotation and the feature/ namespace approach move this identification to the FMRI. In the current implementation, it would be easier to filter out FMRIs that match some pattern, but we could also use tags to this end. As I noted above, I like Mike's revised 2.4.2 example for libgtk. Have a look. 14. Signing. We're going to be signing, cryptographically, the catalogs and manifests. Publishers will have the option of requiring signing, accepting optionally signed transactions, or running without signing. (We'll also be making the SSL handling check the server's certificate.) Because of signing, the test that two packages are *identical* is performed via comparing manifests, and not by comparing FMRIs (or even the timestamp portion of the version). The FMRIs are used for equivalence, which is a weaker relation. 15. Dependencies and stability. At present, we are computing dependencies narrowly, within the collective set of versions involved in the import of a build. These computations will be extended to support more types of dependencies and also to publish against a specific set of packages--we seem to need modes where one computes against a particular image, and against a particular set of incorporations, and possibly against a particular repository or set of repositories. At present, the preference is to examine the actions and compile the requirements of each action into the package FMRI(s) that would provide the components that satisfy those requirements. As noted in #12, we do need to place a stability attribute on each package (and assume Volatile for those packages lacking the attribute). It would be nice if the publication tools had a way to warn about accidental dependency on low stability packages (or dependencies that cross authorities and are of low stability...). Although there are some concerns about the efficiency of the current rename implementation, it handles individual renames well across dependency tree walks. When we update it, the primary issue for stably handling dependencies is managing package splitting. This problem gets more interesting when we recognize that a split may in fact produce two or more packages with different stabilities (as well as that the original dependency need not actually need to split to dependencies upon all of the resulting packages). The dynamic nature of the dependencies on longer timescales is what makes publication-time dependency computations weak, and may ultimately lead us to some kind of capability dependency system. Of course, that's essentially what we're doing with ELF analysis, will do with smf(5) manifest and other filetype analysis shortly, and is one aspect of Mike's feature/ namespace proposal as well. So the real question is: how realistic is it to expect/allow a package publisher to *never* again update their software? 16. Substitution and virtual packages. A number of messages have wondered about making many components interchangeable behind a virtual package. The classic example is sendmail/postfix/ favourite MTA. My concern is that there's a great deal of cost in making a key component node "substitutable" in this sense. I am nervous about designing centrally about what I think is actually a very limited and complex class of components. I guess I'll let this topic run... -- [EMAIL PROTECTED] http://blogs.sun.com/sch/ _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
