On 16 September 2012 09:20, Brian Harring <ferri...@gmail.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 <ferri...@gmail.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
