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

[Axel Beckert]

Hi,

Manuel A. Fernandez Montecelo wrote:
> Subject: [...] proposal to at least remove it from "stable"

Packages are only removed from stable in cases like

* Debian being unable to provide further security support,
* having become obsolete due to a service they were for no more
  exists, or
* because they have been found to contain non-free stuff (like qcad
  recently).

That they should not have been in stable in the beginning is usually
no reason for removal from stable. And even if it were, it would mean
that aptitude-curses(*) would have to be removed from stable, too,
because they're built from the same source package.

(*) I talk of aptitude-curses instead of the aptitude binary package
    to make clear which variant I talk of.

For that reason I modified the Subject line accordingly and focus on
the status quo and future of aptitude-gtk in Unstable (and Testing).

> I don't know why even was allowed to drop into stable for such a
> sensitive/important package,

Because Testing migration is based on source packages, not on binary
packages. If aptitude-gtk shouldn't have made it into stable, neither
should have aptitude (as both come from the same source package).

If aptitude with aptitude-gtk included shouldn't have gone into
stable, it shouldn't have gone into unstable in the very beginning --
i.e. it should have never left experimental.

But it did. So let's not look back or at Squeeze but at the future,
i.e. Wheezy.

> since the last paragraph of the package description is:
> 
>   "This package contains an EXPERIMENTAL version of aptitude
>    that includes a GTK+-based graphical interface. It is INCOMPLETE
>    and may not work properly. If you do not need a GUI or prefer a more
>    stable interface, you can instead use the version of aptitude
>    found in the package "aptitude".

Well, there are quite some packages with a similar warning (like being
"alpha state" software) in stable and work quite well.

Nevertheless, I tried to use aptitude-gtk during the sponsoring
process for 0.6.5-1 (No sponsoring without testing!) and also ran in
quite a lot deficiencies (which I btw. haven't argued about when it
came to sponsoring!) compared to aptitude-curses.

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.

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.

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?

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe at debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-    |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5