You're going to need to expand your rationale for this one.

I presume he's attempting to use pkgrecv/pkgsend to exactly duplicate a
repository.

(In reply to comment #2)
> I presume he's attempting to use pkgrecv/pkgsend to exactly duplicate a
> repository.

If that's the case; I'd rather not oblige.  It's a horribly inefficient way to
mirror a repository.

Yes, to have exact clone of some relatively small subset of resporitoy (of
course, not a whole one) , for example create a local copy of Live-CD content
to test image update which is generated with AI or DC, to generate demo repo
for AI and DC Virtual Applicens and so on.

On discusion threads are scripts which use wget and undocumented repo feautures
to make whole REPO clone (which I will never need), it will be nice if I can do
it right with "pkg recv from public/pkg send to local" and get exact same FMRI
(timestaps).

Alternative option of cource is to supply official tool to which I can put as
parameter a list of FMRIs and get a exact local copy of them.

(In reply to comment #4)
> Alternative option of cource is to supply official tool to which I can put as
> parameter a list of FMRIs and get a exact local copy of them.

I think the tool approach is better as I wouldn't want to solve a
*non*-publishing problem using publishing tools.

It would be far more efficient (and less prone to error) to have a tool focused
on repository management.

It seems like the previously discused "depotadm", once implemented, could have
a "copy" subcommand where you could specify a list (or file containing a list
of) of fmris to copy from another repository.

That would also match up better with the local publishing work I'm doing for
bug 2691 as you could use the tool to easily copy specific packages from one
disk repository to another without ever having to run a daemon process.

Please note that there may be some interesting considerations to resolve here
in regards to authorities.

We (the Update Center project) in SWI also have the need to
be able to selectively copy packages from one repository 
to another without the timestamp being modified.

Making this bug dependent on bug 5562 because of the problem that local times
causes when trying to copy a package from one repository to another.  If the
source repository was running in a timezone east of GMT, then if updatelog
entries are copied directly to a repository that is going to run in a timezone
west of GMT, the catalog update logic will not work correctly in the resulting
repository. If bug 5562 is fixed, then this would not be a problem.

Updatelog entries are really about when a package was added to a repository,
and not when it was necessarily, originally published.

As such, this really isn't dependent on the server local time being UTC.

Doing this is dependent on being able to specify a timestamp when opening a
publishing transaction though.

Also, this functionality was implemented in the changes for bug 6342 and bug
8898.

As for the differing timezone aspect, the best advice I can provide to someone
is to ensure their timezone matches the source repository's until bug 5562 is
resolved.

Implemented in changeset 1118 / f2dd6916517307b5b0dfb4b21de56afed63ec577.

Please note that since the new pkgrecv capabilities are essentially just
republishing an existing package, but with the exact same timestamp as the
original server's, that it doesn't really matter if the destination
repository's timezone matches the source repository's timezone since new
updatelog entries are added to the destination; not copied from the source.

I should also note that while the updatelog entries on the source server are
done in local time, the timestamps assigned to package FMRIs at original
publication are in UTC:

open_time = datetime.datetime.utcnow()