On 06/18/08 01:44, [EMAIL PROTECTED] wrote:
>> Yeah, local replication is maybe that what comes close. So I have done
>> this with a combination of pkgrecv + pkgsend.
>
> I'm impressed that works at all, actually. pkgrecv was intended as a
> way of capturing content for publication elsewhere, not as a replication
> mechanism.
It took some effort to figure this all out. So the mechanism is as
following:
- *pkgrecv -s pkg.opensolaris.org -n* and grep for the packages you want
to replicate
- pkgrecv package
- you get for each package a directory with the *compressed* package
files in it + the manifest
- no create a new repository
- I use a separate zfs with atime=off, compression=on which is important
to be a separate zfs - I come back to this later on.
- then start pkg.depotd for this directory
- now use the package directories to push the packages into your new
repository
- first uncompress all files in the package directories (except manifest)
- now grap the package name out of the first line of the manifest and
run for each package
- eval `pkgsend open <package name>`
- pkgsend include -d <package dir> -i <package manifest>
- pkgsend close
That's it. Now if you look into the repo directory you see a giant
search.pag file (~50 GB or so). So my intention was to put the repo on a
DVD for distribution or offline use. So this file does not fit on any
DVD. Also the performance of such a pkg.depotd running out of the DVD
would suck. So the idea was to create a snapshot of the repo zfs and
create out of this with *zfs send* a plain file, which can be placed on
a DVD. This file can be created within 15 minutes and will be ~1.5 GB in
size. This also can then copied with *zfs receive* onto a local disc to
run locally the depotd. This works really good now for me.
Sorry longer description but maybe of interest for others too.
to follow below ...
>
>> So I get identical packages but in different authorities. It's not an
>> issue today, but if someone wants to upgrade the local provided
>> packages with newer packages coming from opensolaris.org, he would
>> never see that there is an update for his installed package :-(
>
> I once the namespace issues are resolved, authority won't
> matter unless it's part of the package name. In that case, the upgrade
Good and that's what I thought of too.
> between authorities should work seamlessly. I believe you can get
> around this problem today by changing your preferred authority back to
> opensolaris.org and upgrading.
Yes, that works, but also with the authority of opensolaris.org it
should look for packages with the same name (but maybe different
version) in other athorities and ask for upgrade.
>
> If you're asking that your local depot stay in sync with
> opensolaris.org, we're not to the point of having that functionality.
> We're looking at mirroring content, but I'm not sure if we want to
> mirror meta-data. I'll let Stephen comment more on that, if he so
> desires.
>
> As far as having operations be fast on the client, we'd eventually like
> to write a client-side cache. We have the beginnings of that today.
Caching of packages is IMHO only useful for just-in-installation-process
packages, but not forever. Think of small systems, where people have to
live with limited disk space. So the may only want to cache the catalog
and the manifests for packages and tht's it. The one think that might be
useful is a "look-forward" cache, that downloads/caches maybe already
the next to be installed package, while it installes a package.
> The client in the gate will keep ahold of content to speed up download,
> and to recover should a download fail. Eventually, we'd like to have
Ok, for the actual package it's useful, but clear the cache after
successful installation.
> something fancies that hangs around, retrieves files in parallel on
> behalf of the pkg client, and perhaps shares this content if
> appropriate. This would be akin to having your depot run locally, but
> wouldn't provide so many administration headaches (I hope). That's
> still a way out, though.
(I have some feedback about packagemanager and pkg.depotd which I will
send separately here)
Thanks
Detlef
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
