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?
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.
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)"?
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?
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.
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?
Cheers,
-Shawn
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
