* Shawn Walker <[email protected]> [2010-05-18 15:43]: > On 05/18/10 04:57 PM, Stephen Hahn wrote: > > > > Thanks for a thorough write-up. A first batch of questions and > > comments: > > > > 1. Is a .p5i present for all publishers in a v2 repository? Why or > > why not? > > I didn't make it required simply to minimise configuration hassle. > Since we can't require origins or mirrors, in the minimal case, the > only thing it would have is the publisher prefix (which is already > known obviously). > > > 2. I think a .p5i file should be present for all publishers in a .p5p > > archive. > > Is this also true for a repository?
No, based on your answer above. I would really like to see a .p5p as "everything in a .p5i, plus the package contents", and have to .p5p construction tools biased in favour of including at least an origin URL. > > 3. (5.1) Is there any reason not to support http://, ftp://, etc. > > URIs that retrieve .p5p archives? > > Could you be more explicit about what you mean by this? I don't > quite connect this to section 5.1's text. I was hoping that pkg install -g http://example.com/foo.p5p would work. > > 4. (5.4) Using a .p5p archive as an origin is... unusual. I would > > have expected the .p5p to deliver the origin(s) in the included > > .p5i files, the content of any packages within the .p5p, and then > > be safely discarded. The current writeup suggests I have to > > carefully manage my .p5p files, which seems dangerous. Could we > > get the publisher/.p5p lifecycle envisioned in the document stated > > more clearly? > > I don't quite understand the concern about having to carefully > manage .p5p files. > > My assumption here was that .p5p files enable the complete offline > delivery of package data and could be aggregated with any already > existing package data for related publisher(s). > > The intent is that the client works identically to what it does > today, and that .p5p files are simply treated as additional package > data sources that exist only for the duration of a transaction. > > Could you expound a bit on your possible concerns here and/or what > you mean by "deliver the origin(s)"? "Deliver the origin(s)" means that the origin of each publisher in the .p5p is provided in the corresponding .p5i. I am thinking about how "pkg fix" is expected to work for content initially delivered by .p5p. I know we have disconnected sites as a key use case, so archiving the .p5p locally is one way to make pkg fix work. > > 5. "pkg upgrade-image" should probably be "pkg metadata-upgrade" or > > something less like "image-update" (even though I acknowledge > > reversing the noun-verb pattern does make it a bit distinct). > > That's fine; although would 'pkg meta-update' be acceptable? Yep. > > 6. Is there a reason why you don't want to have "pkg install > > ./my_pkg.p5p" mean "install or update all packages in the > > container named ./my_pkg.p5p"? > > I have this, but via the proposed -g option. My reason for > requiring the -g was that I didn't want to confuse input context--as > in, currently we expect package FMRIs only for the positional > operands provided to the install subcommand. Right. > In particular, I believe it would be difficult to provide good error > handling if we accepted both package FMRIs and filenames for input > to the install subcommand. For example, it would mean that package > names couldn't end with '.p5p' (not that I expect they would) and > that error conditions become harder to handle (was the problem that > the user specified an unknown FMRI or a file that didn't exist?). > > If you believe that for the sake of the user, we should accept .p5p > filenames for the positional operand input to the install > subcommand, what criteria or process would you apply in parsing that > input that prevents possible user confusion in an error case > scenario? Good question. I think that if we interpret the operands as URIs, and if those URIs are fully specified, there's no ambiguity. pkg://example.com/my/favorite/package refers to a package retrieved by the origin specifications for example.com file:///home/sch/my-favorite-package.p5p refers to a .p5p archive containing one or more packages. http://muskoka.sfbay/~sch/my-2nd-favorite-package.p5p refers to a .p5p archive containing one or more packages that we have to retrieve via HTTP. Then we have to consider how to handle incomplete URIs. One algorithm is: for o in operands: if stat(o) if o.is_a_p5p_archive(): install.append(o) else: o.may_be_trouble = True if not lookup(o): if o.may_be_trouble: error: o isn't a package archive else: error: no such package as o else: install.append(o) HTTP would require a full URI. - Stephen -- [email protected] http://blogs.sun.com/sch/ _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
