Re: [gentoo-dev] example conversion of gentoo-x86 current deps to unified dependencies

[Ben de Groot]

On 16 September 2012 09:20, Brian Harring <ferringb@×××××.com> wrote:
> On Sun, Sep 16, 2012 at 12:03:36AM +0200, Micha?? G??rny wrote:
>> On Sat, 15 Sep 2012 13:33:18 -0700
>> Brian Harring <ferringb@×××××.com> wrote:
>> > To demonstrate the gain of this, we basically take the existing
>> > tree's deps, and re-render it into a unified DEPENDENCIES form.
>>
>> But in order to do this, we first have to decide exactly what kind
>> of dependencies do we want to have. Then convert the tree to
>> a separate-variable form with new dependencies. Then we can compare
>> it with the DEPENDENCIES form and decide which one is better.
>
> Funny you mentioned that, I just finished tweaking pquery to generate
> real world example unified dependencies; these *are* accurate, just to
> be clear.
>
> Dumps are at
> http://dev.gentoo.org/~ferringb/unified-dependencies-example/ .
>
> Herds, if you want to see what your pkgs would look like, look at
> http://dev.gentoo.org/~ferringb/unified-dependencies-example/herds/ .
>
> If you'd like to see an *example effect* it has on what gets displayed
> to the user (aka, after all major use conditionals are stripped), look
> at
> http://dev.gentoo.org/~ferringb/unified-dependencies-example/user-visible.txt
> ; warning, that's a 55MB file.  The syntax in use there isn't great,
> but as said, it's an example.
>
> Total cache savings from doing this for a full tree conversion, for
> our existing md5-cache format is 2.73MB (90 byes per cache entry).
> Calculating the savings from the ebuild/eclass standpoint is dependent
> on how the deps are built up, so I skipped that.
>
> The algorithim used is fairly stupid, but reasonably effectively;
> essentially it intersects the top level of each individual type of
> dep, breaking out common groupings.
>
> In other words, it won't pick up this:
> DEPEND="x? ( dev-util/diffball dev-util/bsdiff )"
> RDEPEND="x? ( dev-util/diffball )"
>
> and convert it into thus
> DEPENDENCIES="
> dep:build,run? (
>   x? (
>        dev-util/diffball
>        dep:run? (
>          dev-util/diffball
>        )
>      )
>   )"
>
> Additionally, the form used here makes *no assumption about default
> context*; in any final solution we use, a default context would be
> wise- say build,run.  Again, an example of what I mean.
>
> If we said "in the absense of a context, the default is dep:build,run"
> the following:
>
> DEPEND="dev-util/diffball dev-util/bsdiff"
> RDEPEND="dev-util/diffball de-vutil/bsdiff x? ( sys-apps/pkgcore )"
> PDEPEND="dev-python/snakeoil"
>
> would be:
> DEPENDENCIES="
>   dev-util/diffball
>   dev-util/bsdiff
>   dep:run? ( x? ( sys-apps/pkgcore ) )
>   dep:post? ( dev-python/snakeoil )
> "
>
> The quicky algo I used assumes no default context, thus it writes
> this:
> DEPENDENCIES="
>   dep:build,run? (
>     dev-util/diffball
>     dev-util/bsdiff
>   )
>   dep:run? ( x? ( sys-apps/pkgcore ) )
>   dep:post? ( dev-python/snakeoil )
> "
>
> Etc.
>
> ~harring
>

Thanks. I have given it a quick overview for the qt herd. I still
don't see what using DEPENDENCIES adds to what we do now with separate
*DEPEND variables. I see no convincing reason to change what we do.

As I've said before on IRC, we need a good costs/benefits overview.
Right now I only see costs (migrating ebuilds and eclasses) and no
benefits.

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin