[Aptitude-devel] About status of aptitude-gtk -- split off into separate source package? (GSoC project?)

[Daniel Hartwig]

On 20 March 2012 08:49, Axel Beckert <abe at debian.org> wrote:
>
> So I agree that due to the huge quality differences between the
> aptitude-curses and aptitude-gtk, aptitude-curses shouldn't depend on
> aptitude-gtk release-wise.
>
> I think the best solution for both (binary) packages would be to split
> up the source package into two source packages if possible at all.
> Maybe the aptitude-curses source package then needs to provide an
> aptitude-dev binary package or so if code/header files from the
> aptitude-curses source are needed to build aptitude-gtk.
>

I also agree with the sentiments that aptitude-gtk is not fit for
release and should be restricted to experimental--if provided at all.

A source split is possible.  Some observations:

- there is lots initialization code in src/main.cc which is shared
between all interfaces; this should probably be migrated out under
src/generic somewhere.

- everything under src/generic will need to be shared, these are
already built as static libraries to assist in linking, so the step to
a shared library is potentially very small.  Note that many static
libraries are built, where as I think it preferable to expose only a
single shared libaptitude;

- the state of src/generic is very inconsistent.  Some files make good
use of namespaces and interfaces and others are rather adhoc.  Many
interfaces are in flux.

- 0.6.6-1 will see a new package, aptitude-common, containing the
shared arch-independant data (help files, etc.).


It is hard to guage how many people continue to use aptitude-gtk.
Given it's current state I do not think very many.

I agree that in the medium-term a split would be useful, then we could
haev both -gtk and -qt in experimental.  In the mean time we should
either drop the aptitude-gtk binary now or have it issue a warning on
startup that it will be dropped in the near future.


Another issue to consider is that the package manager landscape is
changing in recent years.  There is now things like PackageKit which
we can expect to produce very high quality PM interfaces for the
various toolkits.  There are also many existing PM's that provide a
very good interface under GTK+, etc.

Aptitude-curses has a unique place in this environment.  However, it
has proven difficult to translate this to Qt and GTK+ interfaces and
keep everything in sync between them.  It might be time to simply
delegate the -qt and -gtk interfaces to the archives.


>
> If aptitude-gtk already would be a separate source package, I'd filed
> an RFA or O WNPP bug now, but I'm not sure if filing an RFA/O against
> a non-existing source package causes any problematic side effects.
>

I guess we leave this for now then.


> aptitude-gtk was created as a GSoC project. Maybe we should try to
> find someone to get it in shape as another GSoC project. Ana (Cc'ed)
> already asked if we have some ideas. Anyone would mentor further
> aptitude-gtk developement?
>

I have no knowledge of gtk, nor will I have the time to be a primary
mentor for this.


Regards