Shawn Walker wrote:
On 08/27/10 12:00 PM, Darren Reed wrote:
Shawn Walker wrote:
On 08/26/10 09:06 PM, Darren Reed wrote:
In trying to create a my own package on a private depot, I've followed
the instructions in the man page for pkgsend which start with:
$ eval `pkgsend open [email protected]`
ok, it was obvious that wasn't going to work because there was nothing
in that statement that told pkgsend how to connect to my depotd
(and in
trying it, no it didn't work), so I added the complimentary "-s
http://server:port"; and then ran into this error:
pkgsend: 'open' failed for transaction ID 'None': http protocol error:
code: 400 reason: Bad Request
URL: ...
Additional Details:
The specified FMRI, '[email protected]', must include the publisher
prefix as the repository contains package data for more than one
publisher or a default publisher has not been defined.
What is the "publisher prefix"?
That's explained in the pkg(5) man page.
I'm even more confused by the "Additional Details" as the repository
contains no package data (I've only just started pkg.depotd -d
/directory -p port) to a previously empty /directory.
In order to address the "default publisher" bit of the message
above, I
tried starting pkg.depotd with a small configuration file (pkg.depot
--cfg /tmp/depot.cfg):
[pkg]
port = 8081
inst_root = /tmp/depot
default_publisher = darrenr
but that did not cause the above error to stop being produced.
And it wouldn't; that's depot configuration, not repository
configuration.
To me the way you say that makes it seem like depots and repositories
are completely separate entities. Is that the meaning you intended to
convey?
To look at the first paragraph of the DESCRIPTION for pkg.depotd, I
have:
pkg.depotd is the depot server for the image packaging system.
It provides clients network access to the data contained within a
package repository. pkg(1), the retrieval client, makes requests
to the depot server for catalogs and packages. pkgsend(1), the
publication client, sends new versions of packages to the depot
server. pkgrepo(1) provides creation, management, and summary
functionality for repositories. pkg.depotd is typically run as
a service on the system. Package and software developers may
wish to run private copies for various testing purposes.
So quite clearly the depot server is providing access for clients to
repositories and as such, why wouldn't you configure the repository
through it?
It says *network* access; the pkgsend man page quite clearly states
that you can access a repository directly using file:// URIs.
But the path to the repository is the same as path to the depot given
with "-d" to pkg.depotd, right?
Given that it then seems to me that the depot and repository are one and
the same?
Why do I need to configure a repository independly of a depot?
Because a repository can be used independently of a depot server. The
depot server provides *network* access to a repository.
Ok, that makes sense.
Why can't I configure both at the same time, through the same
configuration file?
Because they can be used independently.
How do I use a depot independently from a repository?
I can understand that I don't need a depot server in order to access a
repository using file://, but I don't understand what I can do with
pkg.depotd that isn't related to a repository - at least the man page
doesn't tell me that I can.
If my depot only ever has one repository, surely this would seem
sensible?
No, see above.
Furthermore, why should it be possible for the default publisher in a
repository be allowed to be different from that of a depot?
A depot can't have a default publisher.
Then why does the pkg.depotd man page list "pkg/default_publisher" as a
configuration knob?
Is that a bug?
Can there be multiple repositories in a single depot?
A depot can't have things "in it"; a depot just serves repositories.
If your question is whether a depot can serve multiple repositories,
that's something still under consideration.
That's counter intuitive to the normal use of the word "depot", when you
think of what a "bus depot" is. I suppose you might say that a "bus
depot" serves buses but there are most definitely buses in it at various
times of the day. A bus depot could be a home to different types of
buses, or even non-bus vehicles, but ... I don't know if you'd say there
were multiple repositories there.
When I look under the depot directory after having run pkgsend to talk
to pkg.depotd, there are a whole lot of new files in the depot directory
(or rather repository directory), including I presume the pkg I created
using pkgsend which would imply that it does have a pkg in it.
FWIW, I think the idea of there being a 1 to 1 relationship between a
depot server and a repository makes a lot of sense. To do otherwise
would seem to require changes to the pkg FMRI.
With an additional bit of playing, it seems like what's required is
this:
pkgsend -s http://server:port open pkg://darrenr/[email protected]
and that made sense. What I was looking for was how to specify only
the
publisher (as part of the FMRI) when what I needed to do was give it a
full FMRI. If I try to just add the publisher
(darrenr/[email protected]), it fails so the error message should
mention that I need to provide a full pkg FMRI rather than just the
"publisher prefix".
Again, see pkg(5) for an explanation of package FMRIs, etc.
More information that I could easily see as being useful on the
pkgsend
man page is:
* that without using "-s ..." it requires a local pkg.depotd to be
running on port 10000 as provided by svc:/application/pkg/server.
That's already in the man page; see the notes under the -s option.
Yes, but there is no explanation of the significance of
"http://localhost:10000";. It might be better reading if the last
sentence of that paragraph said:
"The default value is http://localhost:10000/, which corresponds to the
default settings used by svc:/application/pkg/server."
No, it doesn't correspond to the default settings for pkg/server. The
default setting for pkg/server is actually port 80; not 10000.
The 10000 default is a leftover from early developer use at the
beginning of the project. I'd rather remove the default logic
entirely if it's going to cause this much confusion.
The first examples in the pkgsend man page starts with "eval `pkgsend
open [email protected]`". How is a user expected to use that example as
something that will work?
* if it is possible to just add the publisher prefix without giving a
full fmri, please mention how that should be done as none of the CLI
options or examples illustrate this
Feel free to file RFEs, but I would note that the pkg(5) man page
explains what a publisher prefix is and what FMRIs are and that
pkgsend(1) says to see also pkg(5).
I'd rather not duplicate the material in pkg(5) in other man pages.
The pkg(5) man page does not give an example of an FMRI that contains
only the publisher's prefix plus the name of the package. In fact that
man page has only one FMRI (a fully qualified one) as an example, which
I do not think is enough.
Yes, it does give an example of an FMRI that contains only the
publisher's prefix plus the name of the package. That *is* a "full
FMRI" (whatever that means).
Well pkg(5) mentions "full FMRI", so I assume it has to mean something?
For example, would "opensolaris.org/[email protected]" be accepted by
pkgsend, with it using "opensolaris.org" as the publisher prefix?
If I give pkgsend an FMRI that is composed as "foo/[email protected]", why does
pkgsend not treat "foo" as the publisher?
Because '/' is a valid character in a package name.
For example:
package/pkg
Which is why to specify a publisher, you must include the scheme:
pkg://<publisher>/<package_name>@<version>
...
How does pkgsend, or any other tool that uses FMRIs, know what is part
of the name and what is part of the publisher when a fully qualified
FMRI is not present and the supplied FMRI has at least one '/' in it?
Please file an RFE with suggestions as to how you would like to see
man page text for pkg(5) expanded.
The above comments about a package name being allowed to contain "/" and
that you need to specify "pkg://" in order to supply the publisher are
vital to understanding the format of the FMRI and what syntax is
necessary with pkgsend. I suppose this is implied by it being described
as heirarchical and arbitrarily deep because that implies a package name
can have an unspecified number of /'s in it and thus the only way to
specify the publisher is by starting with pkg://.
I think the more important bit is that with web browsers, I can give it
a URI of "jurassic/foo/bar/baz.html" and it will interpret the
"jurassic" bit as being the server name and everything after the first /
as being the path element at that server. Or to be more correct, I
suppose the client prepends "http://"; and things happen from there.
Whilst the FMRI looks a lot like a web URI, in this regard it seems to
be operationally different. Of note, the smf(5) man page outlines that
unless the FMRI contains "//" at the start, everything following the
svc: is a service name through the use of examples.
Does it make sense to have a fmri(5) man page that lists the full
definition of each FMRI scheme supported?
Is "pkg:/foo/[email protected]" allowed?
Is "pkg:/foo/[email protected]" the same as "pkg:foo/[email protected]"?
And if so, is the publisher just assumed to be whatever the default
publisher is for the depo/repo being accessed?
The pkg(5) man page documents what the full FMRI is but doesn't really
go into detail about what is ok as a partial pkg FMRI even though other
man pages, such as pkgsend's, do make suggestions about what is ok.
It is interesting that for most folks, the name following // in a URI is
that of a server with which to establish contact with to obtain the rest
of the URI from. With pkg: FMRIs, that's not the case. The server needs
to be supplied independently to the FMRI.
Darren
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
