Obey Arthur Liu wrote:
Filipus Klutiero a écrit :
> Christian Perrier wrote:
>> Is this silly to think that, as most of the (good) work was made in
>> aptitude-gtk, an aptitude-qt development would be a better idea?
> At first sight, it does sound silly to me. aptitude-gtk is a GTK+ GUI
> for Aptitude. Similarly, aptitude-qt would be a Qt UI for Aptitude. But
> Aptitude is an APT front-end. Which means aptitude-qt would be a
> front-end to a front-end. We only want a Qt/KDE APT front-end.
To be exact, "aptitude-gtk" is as much a "front-end" of "aptitude" as
the ncurse version of aptitude is, or the console version for that
matter, is a "front-end" of "aptitude".
Well, the description of the 2008 GSoC aptitude project states:
I will create a GTK+ GUI for Aptitude [...]
Aptitude is much more than a bare APT front-end. It embarks its own
elaborate resolver and quite a few other things.
I agree that aptitude may have done more than it was supposed to in the
past, but the current situation is better, and I seem to hear it's still
improving. I'm not an aptitude user; these things may be good or not,
but even if they're good, I think the factorization should continue
rather than mangling things even more.
Also, aptitude-gtk is not just making calls to the aptitude binary or
libraries or whatever, it's an integral part of the code.
> aptitude-foo was tried in last summer's GSoC, resulting in aptitude-gtk.
> It's only experimental, but it not only depends on aptitude, it's also
> part of the aptitude source package. I'm not convinced that an
> aptitude-qt would do much better.
Aptitude-gtk is aptitude and aptitude is aptitude-gtk... The "aptitude"
package in experimental is actually "aptitude-gtk" with the -gtk parts
turned off at build-time.
According to aptitude's extended description, "aptitude is a
terminal-based package manager". I'm far from being an aptitude expert,
but my point is not terminological. I'm just saying that writing
front-ends to a front-end is probably not the best way to go. If
aptitude is as you say still much more than an APT front-end, this may
be an issue worth considering before expanding it (or writing new
software that depends on it, depending on the terminology).
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
