On Sat, 4 Apr 2009 13:31:35 +0200
Sebastian Günther <sam...@guenther-roetgen.de> wrote:
> * Alan McKinnon (alan.mckin...@gmail.com) [04.04.09 09:57]:
> >
> > emerge --lock <some-package-some-version>
> >
> I find this suggestion very good, and would like to ask the more
> experienced participants, if such thing was thought of before.
>
> I'm thinking about some options to freeze a system totally, servers
> would like this, and some options to gradually move back from testing
> to stable.
This is like what I've been working on for myself, keeping the convenience of
emerge world for ebuild revisions but not moving most packages to the next
version.
>
> That was the thing that annoyed me in the last weeks:
> a simple possibility to say: hold this packageversion until it is
> back to stable.
So far, with masking the next major version in package.mask, all I've gotten is
‑rN ebuilds.
It's an ugly mess of scripting, but it did what I intended so far, that some
key packages will stay at current version for a while, some keep closer to
current offerings (or from an overlay, or whatever) and others won't register
at all every time I sync.
>
> So I'm suggesting the following new options for emerge:
>
> --freeze: hold this package version *and* revision
Mask anything '>' current installed ebuild version.
> --hold: hold this package version, but allow revision updates
This by masking '>=' next version is what I did, but:
It'd be helpful to know for this purpose how the versioning of the release
corresponds to the ebuild. Like ${package_major_release_version_position} or
something. I don't *think* that's part of the spec yet.
> --hold-til-stable: hold this package, until it hits stable, and then
> use the stable version.
This should be doable.
> --testing: set the ~x86 keyword for this package and necessary
> dependencies
I think "autounmask" is for that, no? Never used it myself. Unmasking specific
versions is the trick, rather than a blanket unmask for a package. IDK how
that's handled.
If you move package.keywords you'll be offered a downgrade for anything not
stable, grep out the packages (formerly) in package.keywords from emerge -p
world to see if they are still unstable.
> I know that this is done relatively easy for one package, but with
> sets this can become a really powerful feature.
Haven't looked into sets, but it sounds great.
> --copy-to-local: make a local overlay entry for that package
++
> I would gladly help to implement this, but I did not read anything
> about becoming a dev.
I *think* all you need is some way to read the caches and in your favourite
language make something that works. '-)
For example:
https://projects.gentooexperimental.org/eix/browser/trunk/doc/format.txt.in
For /var/cache/eix... and /usr/portage/metadata/cache is pretty
straightforward...
app-portage/portage-utils
small and fast portage helper tools written in C
qcache <action> <args>
: search the metadata cache
These tools probably could be incorporated into a set of scripts to run after
emerge and do things like you want. Since this is important to me as well, I
might just look a little further. ;-)
Cheers,
--
|\ /| | | ~ ~
| \/ | |---| `|` ?
| |ichael | |iggins \^ /
michael.higgins[at]evolone[dot]org
