1 |
In short, I agree with Tucold. Some sort of X-independant but aware (thinking curses here) front end to portage + glsa-checks + ability to select another install root (and throw in neworked eclean while at it) come to mind... I could see this as a useful front end to portage for, ie: managing multiple system images on say, the master node of a cluster ;) If one wants to be really neat feature to such an interface, the ability to install the same package onto multiple roots simultaneously. |
2 |
|
3 |
...my 2c. |
4 |
|
5 |
Eric Thibodeau |
6 |
|
7 |
On 2010-03-20, at 7:44 AM, Auke Booij wrote: |
8 |
|
9 |
> First things first, I would not know why someone should be using a |
10 |
> graphical installer instead of xterm or one of its colleagues. |
11 |
> |
12 |
> Anyway, the problems you are pointing out are exactly what you're |
13 |
> sacrificing by using a GUI, and exactly the reason Gentoo doesn't have |
14 |
> a graphical installer (or one that you should be using, anyway). A lot |
15 |
> of Portage's configuration consists of bash scripts, and any attempt |
16 |
> to fully reproduce their capabilities in a GUI would lead to a big |
17 |
> mess (point-and-click programming, *sigh*). If someone desperately |
18 |
> wants a GUI, it would be for daily Portage activities, and definitely |
19 |
> not for obscure feature x or y. |
20 |
> |
21 |
> Further, resolving dependencies is, in my opinion, outside the scope |
22 |
> of a GUI. Functionality that isn't present in the command-line version |
23 |
> of some program shouldn't be added just for the GUI version. |
24 |
> |
25 |
> That said, I'm sure some people would love a GUI integration of |
26 |
> different package management tools (ie. search, install, sync...) into |
27 |
> one big package, and it would definitely be a nice improvement to |
28 |
> Sabayon. |
29 |
> |
30 |
> tulcod. |
31 |
> |
32 |
> On Sat, Mar 20, 2010 at 12:25 PM, xqyz <xqyzii@×××××.com> wrote: |
33 |
>> On 20 March 2010 11:16, Petteri Räty <betelgeuse@g.o> wrote: |
34 |
>>> |
35 |
>>> Last year we had a project for PackageKit integration that was never |
36 |
>>> integrated into the main tree. I would rather continue that work and |
37 |
>>> then any PackageKit GUI could be used with Portage. |
38 |
>> |
39 |
>> I agree, it would indeed be nice to have a portage integration in |
40 |
>> PackageKit, but given the rather unique way of handling packages in Gentoo, |
41 |
>> I would consider PackageKit to be a rather poor choice for a package |
42 |
>> manager. |
43 |
>> USE flags, inability to resolve circular dependencies properly and of course |
44 |
>> the advanced compile configuration that Gentoo offers are hard, if not |
45 |
>> impossible to be handled by PackageKit. Which is why I think that, even if |
46 |
>> there was a working integration of portage, it would not be used much. The |
47 |
>> problem with Gentoo is that it more often than not requires the users to |
48 |
>> make a choice instead of just settling for a package and clicking install. |
49 |
>> |
50 |
>> --Patrick Lerner |
51 |
>> |
52 |
> |