Nicolas Williams wrote:
On Thu, Sep 10, 2009 at 06:54:31PM -0500, Shawn Walker wrote:
First of all, the whole trust/signing thing is still under design
discussion, so I'm going to ignore anything related to that because I
can't account for what isn't yet designed.
If adding a publisher has anything to do with certificates for manifest
signature verification, then I'd say there seems to be a dependency
between any work on publisher and UIs on the one hand, and manifest
signing / trust work on the other.
As I said, I'm not interested in functionality that hasn't been designed
or discussed sufficiently yet.
As for boot-strapping issue, how do you think the CD image gets built?
An empty image is created, and the packages are installed into it.
There are difficult bootstrapping problems. This is not one of them.
All you need to do to bootstrap this process is to provide any, any two,
or all of: a) a way to manually install TAs, bypassing IPS, or b) an
option to tell IPS to proceed in spite of not being able to validate a
publisher cert to any TA, c) let IPS prompt (in GUI mode anyways) about
pkgs lacking manifest signatures or whose signer's cert could not be
validated to any TA.
As I said, I'm not interested in solving problems I don't have yet :)
So, overkill, as I said. [...]
I don't agree. Again, being able to rely on something that's already
been built (or will have been, by then), namely manifest signature
verification, is a boon. Re-use is a good thing, no?
I don't make the connection that you are. And we already have the .p5i
format, if anything, I'd rather add the signing logic I recently defined
for the catalog to it instead. A package is far more overhead and
complexity than we need for publisher metadata.
Again, I'm not interested in trying to use packages for this. It
creates more problems than it solves for me.
That's not the only UI detail though. What becomes of /release and /dev
in a world in which we have named streams rather than just named
repositories? "Streams", or whatever you want to call them, need to be
first class objects in the UI.
I'm fairly certain what Brock has outlined has proposed that exactly.
I think if I had to summarise the proposal in a nutshell, it's simply this:
* Users shouldn't be adding/removing repositories.
Why not? Mirrors are repositories. If I can create a mirror I should
be able to add it. Who cares what an origin is? It's nice to have them
defined by default, yest.
I'll put it this way, "users shouldn't be adding/removing repositories
to be able to get packages for a specific publisher." In other words,
if they do have to add or remove repositories, it should only be to
*augment* existing information.
* Users should just add publishers to their system (or use publishers
that were already defined on their pre-installed system); the process of
which pre-defines the available repositories, etc. from which we can
derive the available set of packages and streams.
But users should not _define_ publishers. They should only add/remove/
enable/disable publishers.
As long as they're not creating their own packaging repository, yes.
And I don't think anybody intends for them to do so.
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
