[gentoo-portage-dev] Helping out

[gentoo-portage-dev] Helping out

[Jesus Rivero (Neurogeek)]

[-- Attachment #1: Type: text/plain, Size: 403 bytes --]

Hi all,

WRT dolsen's email to -dev:

"...Those interested in joining, please subscribe to the gentoo-portage-dev
list and send an email stating what you can offer and any ideas you have
to improve portage's code base.""

I'd like to help out. I'm somewhat familiar with portage internals and I
know Python.

Let me know what do you need from me.

Cheers,

-- 
Jesus Rivero (Neurogeek)
Gentoo Developer

[-- Attachment #2: Type: text/html, Size: 1401 bytes --]

Re: [gentoo-portage-dev] Helping out

[Sebastian Luther]

Am 06.01.2014 21:46, schrieb Jesus Rivero (Neurogeek):
> Hi all, 
> 
> WRT dolsen's email to -dev: 
> 
> "...Those interested in joining, please subscribe to the gentoo-portage-dev
> list and send an email stating what you can offer and any ideas you have
> to improve portage's code base.""
> 
> I'd like to help out. I'm somewhat familiar with portage internals and I
> know Python.
> 
> Let me know what do you need from me.
> 

I tried to compile a list of bugs for people to get started. If you
aren't interested in any of those, feel free to roam the bugs assigned
to dev-portage. There are more than enough.

Bug 490358 - sys-apps/portage: when using git repo directly, version
should include git sha1 (edit)
Bug 490896 - make.conf `source`: support expanding variables
Bug 489088 - sys-apps/portage-2.2.7: FEATURES='cgroup ipc-sandbox
network-sandbox' do not fail gracefully

Somewhat larger project that needs discussion with the team:
Bug 478384 - sys-apps/portage: repos.conf: support tarball (emerge-webrsync)

Split this bug in small self contained tasks and file a bug for each task:
Bug 480190 - implement GLEP-58 to 61

> Cheers,
> 
> -- 
> Jesus Rivero (Neurogeek)
> Gentoo Developer

Re: [gentoo-portage-dev] Helping out

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1: Type: Text/Plain, Size: 494 bytes --]

2014-01-06 21:46 Jesus Rivero (Neurogeek) napisał(a):
> Let me know what do you need from me.

You can help in porting various functions to not use deprecated objects.
Examples:
  PORTDIR           (when used as internal config variable)
  PORTDIR_OVERLAY   (when used as internal config variable)
  mainRepo          (outside pym/portage/repository/config.py)
  mainRepoLocation  (outside pym/portage/repository/config.py)
  porttree_root

--
Arfrever Frehtes Taifersar Arahesis

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-portage-dev] Helping out

[Sebastian Luther]

Here is another one. This is the first patch mentioned here that touches
the dependency resolver. I'd be nice if we had more people with the
ability to work on it. So if you're interested in that, take a look.

Bug 498122 - portage-2.2.8 takes nearly twice as long to calculate
dependencies for world update

The problem with the patch mentioned in that bug is, that from there on
metadata access (specifically USE needs to be computed) is required to
search for slot operator rebuilds.

I expect that the metadata access can be avoided in most cases. To fix
this bug, I suggest to implement a check that decides if the metadata
access is required.

Here are some hints.

Take a look at the first block of the patch. It's about computing the
'atoms' variable. This variable is a set of all atoms in all *DEPEND
strings of some package ('replacement_parent').

This list is later searched for atoms for which atom.cp is equal to
dep.atom.cp (and which aren't blockers).

Before this patch the whole content of the *DEPEND string was added to
'atoms'. An example:
DEPEND="x? ( cat/foo )" would always result in atoms = {"cat/foo"}, even
if the use flag 'x' was disabled for the package.

The leads to problems in the following case:
DEPEND="x? ( =cat/foo-1 ) !x? ( =cat/foo-2 )".

The code later in the function tries to find a package that matches all
atoms in 'atoms'. Obviously there cannot be any package that satisfies
both =cat/foo-1 and =cat/foo-2 at the same time.

And this is not necessary at all here, because of the way the DEPEND is
written. After evaluating the use conditionals there is always one atom
left. But to figure this out, you need to know USE (the set of enabled
use flags).

Since computing USE is expansive, we'd like to avoid computing it.
Consider the following example:
We're searching for atoms with atom.cp == "cat/foo":
DEPEND="cat/foo x? ( cat/bar )"
No use conditional influences the set of atoms in this DEPEND for which
atom.cp == "cat/foo". There's no point in evaluation them and in
consequence there's no point of computing USE.

I propose to implement a function* that maps (package, cp) to the set of
atoms in the *DEPEND of package for which atom.cp == cp (and which
aren't blockers).

This function should:
	* First decide if evaluating USE is necessary or not
	* Then evaluate the conditionals if required
	* Compute and return the set of atoms with atom.cp == cp.

This function should cache its results. For the case without USE, the
cache should be part of self._frozen_config (contains stuff that never
changes). For the case that needs USE, it should be in
self._dynamic_config (contains stuff that may change between
backtracking steps).

For the implementation of the check you'll want to look at the functions
in portage.dep, specifically paren_reduce (ignore the deprecation
warning, we may have to remove that).

Feel free to ask questions here or on IRC.

hf :)

Re: [gentoo-portage-dev] Helping out

[Sebastian Luther]

And yet another resolver bug:

Bug 419381 - sys-apps/portage-2.2.0_alpha109: emerge autounmask comment
shows confusing "required by" dependency graph


The problem here is as follows:

Assume there are three packages A, B and X on a stable system.

A has DEPEND="X"
B has DEPEND=">=X-2"

X-1 is stable, X-2 is not.

If the user tries to install A and B at the same time, emerge will
detect that X-2 needs to be keyworded. So far so good.

When it prints the autounmask message, it prints these "required by"
messages. It does so by traversing the dependency graph upwards. The
problem is with the choice of the parent of the keyworded package.

In the example above you want that to be B, because B is what makes X-2
necessary. A could just live with the stable X-1.

But there is no logic to check for this. It just picks a random parent.

To solve this bug, you'll need to look at the following functions in the
depgraph class:

_display_autounmask
_get_dep_chain_as_comment
_get_dep_chain

The logic will probably be implemented in _get_dep_chain, but the other
function may have to pass more information down to it.

Note that this problem does not only affect keywording, but all other
things supported by --autounmask.