Danek Duvall wrote:
On Fri, May 15, 2009 at 05:27:54PM -0500, Shawn Walker wrote:
http://cr.opensolaris.org/~swalker/pkg-8724/
- line 375: legal values for collection_type? Or does anything care?
What is this referencing?
pkg.server.api?
depot.py:
- line 809: could this list be kept in publisher.Repository? Or maybe in
the repositoryconfig code?
Not certain; this is a specific list of attributes as opposed to all of
them.
- line 840: another case where we need to return 404 instead of 500 for
some reason, but can't yet?
No, because returning a 500 causes Apache to flip out and stop
forwarding requests to the backend. Also, the HTTP specification says
that a server can return a 404 when it doesn't want to know why a
resource is unavailable.
- line 850: I'm not sure I see the point of being able to name just a
single package.
It is still useful.
Also, more than one package doesn't really work in a GET unless it is
passed as CGI parameters (i.e. ?pkg1=foo&pkg2=bar, etc.) and so far, we
haven't done that syntax with any of the other operations yet.
- line 865: The problem here is that PM gets passed the filename of the
p5i file the browser downloaded already, rather than a URI?
No, the problem is that packagemanager explicitly expects a '.p5i'
extension on whatever it gets passed whether that is a uri or a file
path. See bug 8966.
- line 896: wouldn't '"*" in pfmri' be easier to read?
Yes, but I've decided to drop the '*' support completely to simplify
things for now.
p5i.py:
- shouldn't client/api.py be modified to use these routines?
I didn't want to make any unnecessary client changes due to the current
gate restrictions.
- line 95ff: Like depot.py and repositoryconfig.py, this also has a lot
of hardcoded knowledge of the p5i file specifics. It should really all
be kept in one place.
server/depot.py doesn't have the specifics of the format encoded. Just
the specifics about how to construct a publisher and repository object.
repositoryconfig doesn't have specifics hardcoded either; those are just
repository and publisher attributes and are not specific to the p5i file
format.
The p5i module, by necessity, must have lots of specifics about
publishers and repositories since certain changes or removals could
cause an incompatible rev in the version of the p5i file.
- line 124: Why does "origins" have to be there?
Because the .5pi file could be incomplete. If we didn't find any
origins information, then there is no point in constructing a repository
object.
One thing I'm really missing here is the absence of publisher and
repository uuids. I'm okay with that not coming into this wad, but I would
dump the alias attribute entirely, since I don't think it's useful without
uuids. In particular the example server you set up has "opensolaris.org"
as the name, and "os.org" as the alias. I thought the point was that we'd
have uuids as the "real" names, and "alias" be the human readable name
people would see in their "pkg publisher" output, so that we could better
control the confusion of having client configured three publishers
publishing the same bits rather than just repointing "opensolaris.org" to
whatever stream they wanted to be using.
That doesn't match my understanding of alias and name at all. In fact,
the UUIDs we currently have for a publisher are not to identify the
publiser; they are to identify the image of the client to the publisher.
They are generated (purposefully) on the client side, and that is why
the attribute is called client_uuid.
Furthermore, the name is really the "prefix" of the publisher (such as
opensolaris.org or org.opensolaris) and the alias is a short name that
the user will choose.
Can we switch to using dashes instead of underscores for text attributes?
Huh?
A couple of bugs in the test server:
- http://ipkg.sfbay.sun.com:8009/publisher/0/ gives me a file that has no
terminating newline.
I didn't add one and json.dump doesn't add it. Should it?
- http://ipkg.sfbay.sun.com:8009/p5i/0/SUNWipkg\* only mentions SUNWipkg-um
That was intentional, but as I said, I will be removing the wildcard
support.
Where/how is "origins" set? Is this something that should be based off of
proxy_base? Or is it the origins of the depots you're a mirror of?
The origin(s) of the repository you are a mirror of.
So, if you had:
repos.com/os.org-dev, your origin might be http://pkg.opensolaris.org/dev
Perhaps future questions:
- should cfg_cache just be the .p5i file instead of having to translate
between .ini and json formats?
No, as there is configuration information unrelated to publishers and
repositories stored in cfg_cache. However, my long-term goal is to
eventually just store .p5i files in the repository for the publisher and
repository metadata and not have the information in the cfg_cache at all.
I didn't want to do that now as that would mean an even bigger change to
the existing configuration setup.
- Where do you see the final configuration store being -- in SMF, or in
cfg_cache? My dns-sd patch puts more stuff into SMF, but I suspect
that's not the way you decided to go here at least for convenience.
But assuming the presence of a Python interface to SMF, would you see
preferring that?
I don't think it is practical to store this information in SMF. See
above. Also, the repository needs to be fully usable without SMF, so
either way it needs to be possible for it to be somewhere else if it
isn't in SMF.
This does represent somewhat of a flag-day for depot users. Notably, the
new functionality that has been added will not work correctly until users
update their cfg_cache. In particular, there two sections entitled
"[publisher]" and "[repository]" will need to be updated.
There's no way to notice this on startup and rewrite the file? Or is that
what you're saying here will happen:
The file gets rewritten on startup unless the server is running in
readonly mode, either way the depot/repository admin still needs to
provide the missing information for the new functionality to work
correctly (it will return a 404 otherwise).
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
