[gentoo-portage-dev] [SoC] Idea for emerge

[gentoo-portage-dev] [SoC] Idea for emerge

[Simon Lipp]

Hi all,

To start with, I'm a summer of code applicant. A gentoo mentor (Preston
Cody) suggested me to get in touch with portage developers, so, here I
am ;). Since I don't think you have access to my application page, I'll
explain what I propose. 

When I emerge a new package, there's always at least one useflag which
make me shout "what's the hell this means ?". Now, I have to stop
emerge, grep /usr/portage/profiles/use.desc (crap, it was
in /usr/portage/profiles/use.local.desc),
edit /etc/portage/package.use, and then re-run emerge. And if I'm
unlucky (and I'm often), this useflag has added a new depend which has
a new strange useflag, and I have to start the whole procedure again.
So, I have imagined a new option to emerge, say --interactive-useflags
(the name doesn't matter for now ;)), which will work as this example
(well, these useflags are pretty obvious, but it's an example :p):

$ sudo emerge -vp --interactive-useflags liferea
Configuration of liferea...
debug - Enable extra debug codepaths, blahblahblah [y/N]
gnutls - Adds support for net-libs/gnutls (net-libs/gnutls [I]) [Y/n]
gtkhtml - Adds support for gnome-extra/gtkhtml (gnome-extra/gtkhtml)
[y/N] Y ...
xulrunner - ... (net-libs/xulrunner) [y/N]

Configuration of new package gnome-extra/gtkhtml...
same thing here

[ebuild N] gnome-extra/gtkhtml-3.12.3  USE="-debug -static" 0 kB
[ebuild N] net-news/liferea-1.2.7  USE="dbus -firefox libnotify -debug
-gnutls gtkhtml -seamonkey -xulrunner" 0 kB

Total: 0 package, Size of downloads: 0 kB

Then, emerge will add net-news/liferea gtkhtml
to /etc/portage/package.use and merge liferea normally.

Notes:
 - gnutls - ... (net-libs/gnutls [I]) means that this useflag will add
a depency against gnutls ([I] means that gnutls is already installed)
 - we don't configure gnutls since it's already installed, but we
configure gtkhtml since it needs to be installed (new dependency)

Comments, questions and other are welcome ;)

Regards
-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] [SoC] Idea for emerge

[Marius Mauch]

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

On Fri, 23 Mar 2007 18:10:13 +0100
Simon Lipp <simon.lipp@insa-lyon.fr> wrote:
> [...]
> $ sudo emerge -vp --interactive-useflags liferea
> [...]
>
> Comments, questions and other are welcome ;)

Long standing policy is that emerge is non-interactive (--ask is just a
convenience feature to avoid duplicate dep resolution), and for things
like this a new tool should be created that can focus on user
interaction.
Besides that, I don't really want to think about the implications of
such a feature on backtracking, esp. regarding issues like bug 1343,
and I'd assume users might get rather confused to answer questions that
are then thrown away later. Another (relatively minor) problem is that
the flags set in such a session would have to be made persistent
somehow, and I wouldn't want emerge to mess with /etc/portage/package.*
files (that's a more generic problem though).
As for listing USE flag descriptions, there are already patches
floating around for that (at least TGL wrote one a while ago), and even
if not it would be hardly worth a complete SoC project by itself.

So, nice try, but no go (IMHO)

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] [SoC] Idea for emerge

[Simon Lipp]

> and I'd assume users might get rather confused to answer questions
> that are then thrown away later.
I don't unterstand what do you mean by that...

> Another (relatively minor) problem
> is that the flags set in such a session would have to be made
> persistent somehow, and I wouldn't want emerge to mess
> with /etc/portage/package.* files
Why ? it's just doing something the user will normally do....

> As for listing USE flag descriptions, there are already
> patches floating around for that (at least TGL wrote one a while
> ago), and even if not it would be hardly worth a complete SoC project
> by itself.
My idea was to integrate this with emerge, and this seemed something
not very easy. But I totally agree that it's very easy (too for the SoC)
to make an external tool to do that. So, since you think that emerge is
not a place for that, I'll search for a new idea for the SoC and try to
make this simple tool next week ;)

Regards
-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] [SoC] Idea for emerge

[Alec Warner]

>> and I'd assume users might get rather confused to answer questions
>> that are then thrown away later.
> I don't unterstand what do you mean by that...
>

It's a chicken and egg problem.  Portage's job is to examine your systems
configuration (key here is USE flags) and the calculate dependences based
on those flags (among other things).  So in order for your idea to work
with 1 round of dependency resolution; emerge basically needs a
backtracking dependency resolver.  Take the following use case for
example.

new-awesome-emerge foo

foo has 3 use flags, [bar,-baz,-snuffles], bar is enabled by your existing
configuration.

Do you wish to enable baz? (Y/N): Y
Do you wish to enable snuffles? (Y/N): Y

* At this point because you have changed USE flags you have invalidated
the previous dependency graph (new USE flags enabled means new deps might
get pulled in or excluded).  So every time someone adds (or removes) a
flag you need to recalculate deps or your dependency tree will be wrong.

This whole issue can be solved by adding or removing flags from
/etc/portage/package.use instead of /etc/make.conf

However this leads us into the next point.

>> Another (relatively minor) problem
>> is that the flags set in such a session would have to be made
>> persistent somehow, and I wouldn't want emerge to mess
>> with /etc/portage/package.* files
> Why ? it's just doing something the user will normally do....
>

It's been a long standing policy not to touch user configuration.  I can
think of only 1 instance when we currently do it and thats when we process
updates/ and notice a package move; we have to rename that CP in all
configurations so the user doesn't get their system in a weird state.  The
problem with editing stuff like this is usually that when users and
machines edit the same file; bad things happen.  It is hard for the
machine to know what the user is doing in there; and vice versa.

>> As for listing USE flag descriptions, there are already
>> patches floating around for that (at least TGL wrote one a while
>> ago), and even if not it would be hardly worth a complete SoC project
>> by itself.
> My idea was to integrate this with emerge, and this seemed something
> not very easy. But I totally agree that it's very easy (too for the SoC)
> to make an external tool to do that. So, since you think that emerge is
> not a place for that, I'll search for a new idea for the SoC and try to
> make this simple tool next week ;)

Emerge is a big piece of shit (honestly) and it does way too much already,
no need to add more stuff to it, imho.  The biggest problem you will
encounter is that adding and removing use flags is an interative process.

-Alec


-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] [SoC] Idea for emerge

[dol-sen]

Quoting Simon Lipp <simon.lipp@insa-lyon.fr>:

> > and I'd assume users might get rather confused to answer questions
> > that are then thrown away later.
> I don't unterstand what do you mean by that...
> 
> > Another (relatively minor) problem
> > is that the flags set in such a session would have to be made
> > persistent somehow, and I wouldn't want emerge to mess
> > with /etc/portage/package.* files
> Why ? it's just doing something the user will normally do....
> 
> > As for listing USE flag descriptions, there are already
> > patches floating around for that (at least TGL wrote one a while
> > ago), and even if not it would be hardly worth a complete SoC project
> > by itself.
> My idea was to integrate this with emerge, and this seemed something
> not very easy. But I totally agree that it's very easy (too for the SoC)
> to make an external tool to do that. So, since you think that emerge is
> not a place for that, I'll search for a new idea for the SoC and try to
> make this simple tool next week ;)
> 
> Regards
> -- 


Take a look at porthole's cvs trunk branch.  I am nearly finished getting things
ready for the next testing & release.  It should work ok, still some bugs to
work out, some code to finish.  I have extended the dependency view for a
package with a lot more info.  I have also set it to follow the dependencies
deeper (which already include use flags, both used and not used).  A new feature
also makes any dependency clickable to bring up a new window with that package's
notebook detail.  It also allows you to click it's dependencies for more popups,
adjust use flags, keywords, etc..  The cli is great, but gui's are better at
showing large groups of info like variable dependency graphs so you can get it
right before you start the emerge.

P.S. If your looking for something to do, I can always use a hand :) especially
on the portage/pkgcore interface side.

The cvs is not yet installable, but works from the directory it is checked out
to.  Make sure you have the dependencies installed.  From a terminal, cd into
the directory, "./porthole -l -d ALL"




-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] [SoC] Idea for emerge

[Simon Lipp]

> Take a look at porthole's cvs trunk branch.  I am nearly finished
> getting things ready for the next testing & release.  It should work
> ok, still some bugs to work out, some code to finish.  I have
> extended the dependency view for a package with a lot more info.  I
> have also set it to follow the dependencies deeper (which already
> include use flags, both used and not used).  A new feature also makes
> any dependency clickable to bring up a new window with that package's
> notebook detail.  It also allows you to click it's dependencies for
> more popups, adjust use flags, keywords, etc..  The cli is great, but
> gui's are better at showing large groups of info like variable
> dependency graphs so you can get it right before you start the emerge.
> 
Great :). I'll probably test it tomorrow.

> P.S. If your looking for something to do, I can always use a hand :)
> especially on the portage/pkgcore interface side.
Right now, I'm very busy, but I'll have a lot of spare time next week
for 2 or 3 weeks. So, if you need some help... just ask ;)
-- 
gentoo-portage-dev@gentoo.org mailing list