Re: [gentoo-portage-dev] Re: About system and world
On Mon, 22 Oct 2007 21:29:02 -0700 Zac Medico [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ryan Hill wrote: Zac Medico wrote: implement greedy atoms for the world set. I've been pondering the idea of making world non-greedy for slots by default [1], since you can add slot atoms to the world file to pull in any specific slot(s) that you want. That would rock. Portage always insisting on pulling in the highest SLOT whether needed or not is one of my biggest pet-peeves. Well, you can already use SLOT atoms in your world file if you don't want the highest available. Packages that pull in =foo are a different story though. I suppose we can add something like a - --upgrade=minimal option that prevents pulling in new slots if they aren't required. Don't restrict it to SLOTs though. minimal implies that only upgrades required to satisfy the depgraph are performed. The described behavior should be another value, e.g. no-slot-change. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-portage-dev] Re: About system and world
On 2007/10/23, Marius Mauch [EMAIL PROTECTED] wrote: On Mon, 22 Oct 2007 21:29:02 -0700 Zac Medico [EMAIL PROTECTED] wrote: Well, you can already use SLOT atoms in your world file if you don't want the highest available. Packages that pull in =foo are a different story though. I suppose we can add something like a - --upgrade=minimal option that prevents pulling in new slots if they aren't required. Don't restrict it to SLOTs though. minimal implies that only upgrades required to satisfy the depgraph are performed. Couldn't this minimal behavior just be triggered by lack of the --upgrade option (emerge -D set)? Actually, the current --upgrade behavior (with or without --deep) is a bit weird imho, i would prefer something like this (with foo being either a set or an atom): * emerge foo: do the minimum upgrades or new installs required to get foo satisfied. Only its direct deps are checked (and direct deps of the unsatisfied ones, etc.), with the minimal heuristic (upgrade them only if stricly required). * emerge -u foo: do all required new installs and possible upgrades of foo. Only its direct deps are checked (and direct deps of the unsatisfied ones, etc.), with the minimal heuristic (upgrade them only if strictly needed). * emerge -D foo: do the minimal upgrades or new installs required to get foo satisfied. Also, check all of its direct and indirect deps, with the minimal heuristic (upgrade only if strictly needed). * emerge -uD foo: do all required new installs and possible upgrades of foo. Also, all its direct and indirect deps are checked, and upgraded where possible. For those who wonder, and if i'm not mistaken, current behaviors of this four combinations, expressed in those words, are: * emerge foo: do all required new installs and possible upgrades of foo. Only its direct deps are checked (and direct deps of the unsatisfied ones, etc.), with the minimal heuristic (upgrade them only if strictly needed). = same as my emerge -u foo * emerge -u foo: do all required new installs and possible upgrades of foo and its direct deps. Also, check all of their direct and indirect deps, with the minimal heuristic (upgrade them only if strictly needed). = i don't see usefulness of this special case. Whether some code is direct or indirect dep is often subject to some maintainer's choices, and may vary with time (for instance, an internal lib of a big package being splitted out as a separate dep of this package). * emerge -D foo and emerge -uD foo : do all required new installs and possible upgrades of foo. Also, all its direct and indirect deps are checked, and upgraded where possible. = same as my emerge -uD foo. But waste of one of the four options combinations. -- TGL. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-portage-dev] Re: About system and world
On Tue, 23 Oct 2007 21:11:48 +0200
Thomas de Grenier de Latour [EMAIL PROTECTED] wrote:
On 2007/10/23, Marius Mauch [EMAIL PROTECTED] wrote:
On Mon, 22 Oct 2007 21:29:02 -0700
Zac Medico [EMAIL PROTECTED] wrote:
Well, you can already use SLOT atoms in your world file if you
don't want the highest available. Packages that pull in =foo are
a different story though. I suppose we can add something like a
- --upgrade=minimal option that prevents pulling in new slots if
they aren't required.
Don't restrict it to SLOTs though. minimal implies that only
upgrades required to satisfy the depgraph are performed.
Couldn't this minimal behavior just be triggered by lack of the
--upgrade option (emerge -D set)?
--upgrade != the current --update (at least that's what I assumed)
Actually, the current --upgrade behavior (with or without --deep)
is a bit weird imho, i would prefer something like this (with foo
being either a set or an atom):
Yes, --update has a history of being a mess of random behavior.
Personally I'd drop it completely, or alias it to --noreplace.
* emerge foo: do the minimum upgrades or new installs required to
get foo satisfied. Only its direct deps are checked (and direct
deps of the unsatisfied ones, etc.), with the minimal heuristic
(upgrade them only if stricly required).
* emerge -u foo: do all required new installs and possible upgrades
of foo. Only its direct deps are checked (and direct deps of the
unsatisfied ones, etc.), with the minimal heuristic (upgrade them
only if strictly needed).
* emerge -D foo: do the minimal upgrades or new installs required
to get foo satisfied. Also, check all of its direct and indirect
deps, with the minimal heuristic (upgrade only if strictly needed).
* emerge -uD foo: do all required new installs and possible
upgrades of foo. Also, all its direct and indirect deps are checked,
and upgraded where possible.
Maybe --upgrade as name was an unfortunate choice, --resolver might be
better. What I'd like ideally (as a user) is to replace --update,
--deep, --noreplace and --emptytree with the following options:
--resolver={minimal,noslotchange,leastchange,default}
minimal: select the lowest possible version
noslotchange: like default, but try to avoid slotchanges
leastchange: select the version with the smallest version delta
compared to the installed version, otherwise like default
default: current behavior
--rebuild={never,always,changeduse,newuse,changeddeps,selected}
never: never rebuild packages
always: always rebuild packages (like current --emtpytree)
changeduse: rebuild packages if $USE has changed
newuse: rebuild packages if $USE or $IUSE has changed
changeddeps: rebuild packages if any of its direct dependencies were
updated
selected: rebuild the selected arguments (root nodes)
--deplevel=n
check n level of dependencies for updates (with -1 == infinite)
of course all dependencies have to be satisfied, this controls only
what deps should be checked for optional updates
current defaults would be --resolver=default --rebuild=selected
--deplevel=0
--update would be --rebuild=never --deplevel=1
--deep would be --deplevel=-1
--emptytree would be --rebuild=always --deplevel=-1
But that's just me dreaming of a better world, where we don't have
to deal with legacies ;)
Marius
--
Public Key at http://www.genone.de/info/gpg-key.pub
In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.
signature.asc
Description: PGP signature
Re: [gentoo-portage-dev] Re: About system and world
On Wed, 24 Oct 2007 00:03:47 +0200 Thomas de Grenier de Latour [EMAIL PROTECTED] wrote: Bah, you're introducing a new options set, and have (i think) ways to emulate all of the old ones with them, so what is stopping you? You would just have to forbid mixes of old style and new style on the same command line. Mainly the work required to implement it ;) And I'd rather finish dynoparse first so it can be used here. Oh, and ideally the mentioned values wouldn't be hardcoded lists, but come from a pluggable resolver system, but that probably counts as overengineering. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
