Bug 603386 – Split User package request with portage depends

• Product: Portage Development
• Status: UNCONFIRMED ---

[Description Lagu 2016-12-21 21:22:34 UTC]

Hi all, i want request this change, actually gentoo have a nice way to can handle package versions, and emerge normally can solve depends and say for example what packages we need unmask to can have the packages we need works.

Now i think the conflict is we are locating the packages we want be in the system (or we don't want anyway what we need) and the depends in the same folder, and i think this is a disadvantage, because portage is unable to recognizes what it really need of the depends of our packages, a little ex:

i want the foo package in at least the version 2, so i add it to the file:

echo 'cat/foo-2 ~amd64' >> /etc/portage/package.accept_keywords/local

but now portage says we need the fuu package in version 3 to can install it, so now we need add it to other file

echo 'cat2/fuu-3 ~amd64' >> /etc/portage/package.accept_keywords/foo

and now we can install and all fine, but now the system will interpret fuu-3 and foo-2 are requested in the same way/context, so if there with some package combination where we can skip upgrade to fuu-3, portage will can't detect it, and finally the system is more unstable, specially if we have a lot of experimental packages.

Well, i think a solution can be make a system folder inside the subfolders of what portage can need change to comply the requirements, and in that way portage will know the packages specified in that folder don't need to be obligatory in the tree, are only to can cover what need for the system, and in that way have more posibilites and flexibility.

so rewriting the above example can be something like:

echo 'cat/foo-2 ~amd64' >> /etc/portage/package.accept_keywords/local
echo 'cat2/fuu-3 ~amd64' >> /etc/portage/package.accept_keywords/system/foo

Other advantage of this is we can write automatically files into the system folder with the '--autounmask-write' option without cause confusion in the intention of the change, in some way the idea is the system folder be managed by portage instead of the user.

The idea is apply this concept to package.accept_keywords, package.use, and basically all folders what portage can need do some change to comply the requisites to build the system

Thx. Cya.

[Comment 1 Mike Gilbert 2016-12-21 21:28:57 UTC]

I'm having trouble reading this request, but I'll forward it to the portage team nonetheless.

[Comment 2 Lagu 2016-12-21 21:45:55 UTC]

Hi, sorry my poor english, can you say what parts don't are clear please? i'l try fix that explications.

[Comment 3 Zac Medico 2016-12-21 21:49:30 UTC]

Maybe this is a duplicate of bug 405297? For example, if you create a file named /etc/portage/package.accept_keywords/zzzzz-autounmask then portage will write your "system" changes there, since it used the last file in sorted order.

[Comment 4 Lagu 2016-12-21 21:55:10 UTC]

Hi, sadly the intentions are very differents, this issue can help in that but don't are the same, here the idea is split what packages we are requesting, and what packages portage request to can install the user request, and obvs change the behavior with this data because the meaning of why we are installing that packages are different.

[Comment 5 Brian Dolbec (RETIRED) 2016-12-22 07:18:16 UTC]

Zac, from what I can decipher, it is a variation of that other bug.

He/She wants to keep track of the deps in a separate file for each pkg that emerge needs to satisfy the deps of the pkg he/she added to the /local file.

local:  <== manual entry
    foo-1.2.3
    bar-1.1.0

foo:   <== auto-entry
    baz-3.2.1
    bazinga-4.5

bar:   <== auto-entry
    pybar-7.8.0
    pynacl-1.2.3

...

Lagu, there is already something similar done, but just not in separate files.

It will add comments above the pkg entries stating the dependency chain needing the change(s).

So, I think this would be a no, it is too similar to what is already in place, but more important, I think it would be too much work for so little gain.

[Comment 6 Lagu 2016-12-22 07:36:01 UTC]

Hi, sorry if i'm not can explain correctly this, write that info in a separate file, folder, anything, is only a way to the change proposed here, the idea is change the behavior of emerge over that packages, in the actual way emerge detect all files in the folders to be compliments, but i think is the problem, we store basically 2 types of packages, what we need, and what need of what we need.
So following that, emerge detect all this as request without distinction, while the only packages need to absolutely required is what user need, not the depends of that packages, so i think the behavior can be changed, check and construct the tree with the packages requested for the user, while the extra depends we could need we can see if are available in this new file/folder, with this the depends of what we want don't will affect directly the decision of emerge, and we can avoid up versions when we don't need it.

[Comment 7 Lagu 2016-12-24 08:01:50 UTC]

mm, lets try other explanation...

lets use as reference the actual propose, in system folder depends, and in the mainfolder the packages we want or need.

For the packages in the mainfolder try keep the same behavior as now, all that versions, use, etc, must by satisfied by portage.

For the packages in the system folder are packages to be optional to be used if portage requires it, so if no package need up to unstable version even if the package is listed here portage will not use it.

I hope this can be more clear.

Thx. Cya.

[Comment 8 Zac Medico 2016-12-25 03:15:02 UTC]

I think what you are describing is very similar to bug 258371. The idea is that the config files would only contain user settings, and other settings that are needed just to satisfy dependencies would be managed automatically.

[Comment 9 Lagu 2016-12-25 04:05:12 UTC]

Hi, i think have some parts in common, but the base of the issue i think are differents, there is proposed an auto-use when is needed, but here is proposed change the behavior in packages when the user don't exactly need, only in the depends, obvs that issue can be applied directly to the way proposed here, bat i think are differents.

mmmm, lets try a practical example, similar i write above but more.., clear?

this is the way i want propose (if the problem is fixed in other is fine too):

i need the package foo, so i enable it:

echo "foo" >> /etc/portage/package.accept_keywords/local

but now portage says we need fuu package in a higher version too to can install it, so now we add it:

echo "fuu" >> /etc/portage/package.accept_keywords/system/foo

now we install, all fine, now lets suppose the next version of foo don't need a higher version of fuu, or any where the fuu package we don't need up his version, so, with the proposed way when we upgrade the system portage should downgrade fuu to their stable version, because even if is in the accept_keywords folder don't is really needed so avoid use the unstable version.

Something like that, you know, split packages we want, and depends of packages we want...

All the other issue to implement auto-use, auto-keywords and similar can be complemented with this.

Thx. Cya.