Let me try and answer some of my own questions after some more thinking
and experimenting with IPS...
Darren Reed wrote:
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 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.
...
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.
If I stop thinking about "pkg.depotd" as being a "depot" and just think
about is "pkg.repod" but with the wrong name, then it totally makes sense.
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.
A question that I cannot resolve for myself is:
why is the URI used with pkg(5) a FMRI and not a URI or something else?
And how do I use the pkg(5) syntax to help with "fault management"?
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.
The reason for this dawned on me...
The goal is to allow "pkg install bash" (for example.) Whilst packaging
tools for other free unixes allow that, they do so by building in places
to look for a package - or at best, allow you to provide a list of
servers in a file of some sort. OpenSolaris takes it a step further by
allowing you to configure where to search for packages without using a
text editor on a file. Thus there is no reason to require that a server
name be present in the pkg:// syntax, only some sort of key (publisher)
to find a particular server if so desired.
The question that's left nagging is can I install a package via direct
download rather than from a depot server? e.g.: should this be possible?
# pkg install
http://www.videolan.org/downloads/solaris/vlc-1_1_3-s11-x86.pkg
Darren
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
