On 05/18/10 06:00 PM, Stephen Hahn wrote:
* 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.
I was assuming that there may not be an origin URI because the software
may only be distributed in an on-disk form. I agree that it should be
encouraged though.
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.
I don't see why not, although it does mean that the target archive has
to be retrieved before the operation can even start.
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.
A simple compromise for the moment would be to simply cache any package
data requested from a .p5p archive in the client's download cache for
now. That would at least make the .p5p case no worse off than the pkg
fix for offline or no longer available publisher case. I could also add
-g support for pkg fix.
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.
This seems like a tractable solution to me. I'll update the proposal
accordingly (although I'll likely omit the exact implementation from the
document).
Cheers,
-Shawn
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
