Danek Duvall wrote:
On Mon, May 18, 2009 at 06:14:33PM -0500, Shawn Walker wrote:
What is this referencing?
pkg.server.api?
Yup, sorry.
Okay, I fixed it then.
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.
If I were to add a new attribute, how would I know to add it here as well?
Or whether to add it at all?
This will be moot since the long-term goal is to store the publisher
data in a .p5i file, so instead of having to know what the attributes of
a publisher and repository are, the server will just call p5i.parse() on
the .p5i file stored in the repository and get back a publisher object.
- line 850: I'm not sure I see the point of being able to name just a
single package.
It is still useful.
A claim you make without any substantiation. Though I don't now remember
what it was I was missing. <sigh> Stupid known unknown unknowns.
Well, its obviously useful since that allowed me to enable 1-click
installs from the web interface. Don't forget that you can do wildcards
on the package stem now as well.
Ultimately though, I never really intended this functionality to be used
as a custom .p5i file generator.
However, if there is true utility in being able to name multiple,
specific packages, I'm open to a version 1 of this operation that allows
that. But at the moment, I didn't see how that would fit with how we've
architected our other operations.
One thing that really annoys me about the depot right now is the fact
that our operations are not consistent about how they expect arguments;
they seem to spastically vary between using the uri and POST data.
I'd rather we use query strings for everything (except file upload
obviously).
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.
You'd be replacing code with calls to identical code. Since SUNWipkg is
still a monolithic package, I don't see that it's terribly unsafe. <shrug>
Just make sure this gets fixed once the restrictions are lifted.
They are nearly identical, but not quite. I did change a few minor
things to fix some bugs in location parsing, but the file format is
identical. It really was just caution on my part. I didn't want to do
anything that could cause problems if we needed to respin for the client.
I filed bug 9025 for this.
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.
Again, the problem is that you have three different places you need to go
to enhance these data structures, without any guidance as to what kind of
changes you need to make in each (and that assumes you actually know about
all those places in the first place). I'd strongly recommend finding a way
to encode all the data you need to know about each of the attributes in a
single place, so that all consumers need only look at the attribute
metadata to decide how to manipulate the attributes.
I'm not sure how to accomplish that. First of all, consumers of the
object can't just blindly get a list of the attributes of an object and
then expect to pass them into the object constructor. Second, depending
on how those consumers store their data to construct the object, they
may need to alter or otherwise massage the data into a format
appropriate for constructing the object.
Finally, I would note that the pkg.client.publisher module has a note
about the fact that it is considered part of the client api and that any
changes to it have to be documented, and any relevant consumers updated.
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.
Okay. I thought we were going to move to uuids for canonical identifiers,
provide suggested user-friendly names for them, but allow people to name
them as they wished.
I'm not aware of it; but you're more in the loop than I am.
Nothing consumes any of these attributes yet, right?
Which attributes?
Can we switch to using dashes instead of underscores for text attributes?
Huh?
For example, "refresh_seconds" -> "refresh-seconds".
Are you talking about the repository configuration file?
I didn't do that because “+” and “-” are not allowed in variable names
in Python.
I know that the repository configuration file itself might allow it, but
I guess I'm lost as to the purpose here.
Also, refresh_seconds isn't a text attribute; it's a numeric attribute.
I'm really confused now...
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?
I don't know whether it should or not, but if you know that the stream is
over, you should make sure that there's a newline at the end. If that's
written to a file, it won't have a terminating newline, and that just tends
to be a pain in the ass.
Well, I'm not the one "writing the file" in this case. The simplejson
module is "writing the file" (via dump) and it doesn't add a terminating
newline. So should I stick with the python module behaviour or check
for and manually add a newline?
I'll open a bug if that's what you want.
No, as there is configuration information unrelated to publishers and
repositories stored in cfg_cache.
You mean the feed section?
Yes, and possibly others in the future.
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.
So each publisher would be represented by a p5i file in the depot config
directory, and the depot would read both those and the cfg_cache file?
There will only be one publisher per repository as far as I'm aware.
But yes, the plan was to have the repository configuration parse both
and make them available via the repository api, and then the depot would
use the repository api to obtain the information.
I don't think it is practical to store this information in SMF. See above.
See what above, exactly? What's impractical about storing this information
in SMF, other than we don't yet have a good interface to do so?
My other thought was that this information is metadata about the
repository and doesn't belong in SMF. SMF should only be used to
configure the *depot* server itself since that is the server it is managing.
In addition to that, the depot server is expected to eventually serve
multiple repositories so I believe it is even more important to further
separate the repository and depot aspects.
I don't really view the publisher metadata as configuration to be
managed so much as metadata much like the package metadata that exists
in the repository.
Cheers,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
