[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Packages still depending on GTK+ 1.2



On Mon, 8 Dec 2008 21:49:09 +0100
Morten Kjeldgaard <mok@bioxray.au.dk> wrote:

> One of the purposes of Debian and the FOSS community is to make it  
> possible to develop and distribute software  that is authored and  
> supported by volunteers. 

True.

> We have a responsibility of supporting  
> software components that are still being used by people.

Hmmm, no - not completely, not even if you add the missing "free" in
front of 'software components'. Still being used is not a safe or sane
criterion, still being supported is more important. Bit rot is the
constant enemy and there is no good reason to retain unsupported code
in Debian. You say you have offered to maintain gtk1.2 but that is not
the complete solution - it is dead upstream and that severely
compromises the "value" of merely having a willing maintainer in
Debian, unless that maintainer also takes over upstream maintenance of
the codebase which, frankly, makes absolutely no sense.

Again, I have done this and I continue to do this - I try never to
speak from a position that I have not experienced personally. Taking
over upstream is a significant burden and it is immensely stupid to
take over maintenance of a codebase that has already been replaced and
for which a clear, supported and proven upgrade path is both well
established and thoroughly debugged. 

For one thing, such a choice glibly ignores all the bug fixes made in
the new version - those simply cannot be backported to gtk1.2 because
the bug fix needs to be implemented via a restructuring of the code
that will force a SONAME bump.

> There are  
> people other than Debian Developers using the distribution, they
> might not be using the latest versions of the toolkits, but that is
> their choice. 

Then their choice can be supported by oldstable. That is no
justification for using gtk1.2 with newly written code in unstable.

Choices have consequences - one consequence of choosing gtk1.2 for
newly written code is that people who know a whole lot more than you
about writing secure, portable, usable code get a chance to laugh at
you hysterically because you made such an insane choice. The fact that
someone chooses gtk1.2 does not mean that Debian has any responsibility
to include that code - in fact it means the exact reverse.

Debian has a responsibility to provide stable, secure, portable code.
gtk1.2 is none of those things, not any more. I have written code
using it, I have debugged code written against it, I have ported
packages away from it and I can say with some degree of certainty that
gtk1.2 is *not* stable, secure or portable against the versions of
other libraries in unstable. Things have moved on and gtk1.2 has been
left behind - DELIBERATELY. That situation can only ever get worse -
nothing will ever be improved within gtk1.2 - that alone makes it
insane to write new code that uses gtk1.2.

How are you going to fix a new security bug in gtk1.2 should it come
along?

> As long as there is interest in the FOSS community for
> a specific component, it should be maintained in Debian.

WRONG WRONG WRONG. As long as there is SUPPORT in the FOSS community
for a specific component then it CAN be maintained in Debian. There is
no 'should' involved. Debian has absolutely NO responsibility to
package any specific piece of software, especially unsupported
libraries. Support means upstream support, not merely a Debian
maintainer. Nobody can require that Debian contains a specific package.

I've said this many times, Debian is categorically not a dumping ground
for every piece of bit rot free software on the internet and beyond. I
deliberately include gtk1.2 in the category of bit rot software.

Equally, I will consider libqof1 (my own upstream library) bit rot
software as soon as I release libqof2 after Lenny. Don't come crying to
me looking for support for libqof1 after that date as the reply is
guaranteed to offend. I have taken sufficient steps to ensure that all
reverse dependencies can already work with libqof2 but this is easy for
me because there aren't many of them. The problem with Gtk is the sheer
weight of reverse dependencies and the sad reality is that some of
those packages *MUST* die simply to ensure that gtk1.2 can be laid to
rest in peace for evermore. gtk1.2 deserves to be removed - it is
unsupportable and your offer to maintain it makes me seriously doubt
whether you understand what is actually required to do so.

> I am not saying that all rdepends of GTK+ 1.2 should be kept in the  
> distribution. My position is that it is too early to retire the  
> library GTK+ 1.2. I have offered to maintain it.

Maintaining it is insufficient and taking on the upstream codebase is
completely insane. The code is dead, long long dead. There are no sane
reasons to use gtk1.2 code in any newly written code - that includes
within gtk1.x itself. If you doubt my assessment, speak to any of the
authors of gtk1.2.

> If you want to change my opinion on this, you have to present valid  
> arguments and not ridicule and/or exaggerations.

I think I have the knowledge and direct experience necessary to put
forth such arguments and I believe that I have earned the respect of
many people in Debian for the quality and quantity of my work both
inside Debian and on a multitude of upstream projects that support
Debian packages. Do not think that I speak from a position of ignorance
of gtk1.2 or of the work involved in porting packages to gtk+2.0.
Indeed, I get the impression that I have far more direct experience of
precisely this task than you. I wrote gtk1.2 code, I've ported gtk1.2
packages to Gtk+2.0 (not all successfully) and I have started up new
upstream projects from a clean codebase directly to Gtk+2.0 support,
as well as using this knowledge to help port other Debian packages to
Gtk+2.0, as with gdis.

I therefore make a bold statement to you: If you want to change *my*
opinion on gtk1.2 you are going to have to present valid arguments for
retaining it because in my opinion, none of your arguments to date have
withstood a perfectly rational and purely technical critique.

In my not so humble opinion, gtk1.2 is wanton bit rot. It is unsafe to
use as a development platform, nobody with any respect in Debian or
outside would recommend using gtk1.2 for ANY newly written code - least
of all the GTK upstream developers who wrote the code in the first
place. Even patching gtk1.2 to improve the code is, IMNSHO, a lesson in
abject futility because there can be no possible justification for not
using the proven upgrade path to Gtk+2.0.

I assert these statements as self-evident with regard to gtk1.2:
1. It is wholly and completely deprecated code.
2. No upstream support has existed for a prolonged period of time and
nobody has seen fit to step in - I would propose that this is due,
in no small part, to the proven upgrade path to Gtk+2.0
3. There is no justification for using gtk1.2 with newly written code.
4. Applications using gtk1.2 have already had a very prolonged period
during which to achieve the necessary port to Gtk+2.0 - including
GnuCash which is commonly accepted as the one mainstream Gtk
application with active upstream support that had the longest and most
difficult transition to Gtk+2.0

All of this is evident merely from the authors of gtk1.2, without
getting into the details of distributions.

Proposing any further extension of support for gtk1.2 is proposing to
further undermine the development of free software by the retention of
outmoded, insecure, abandoned code that gets worse and worse with every
year. gtk1.2 is a horror story from the perspective of 20:20
hindsight; the codebase reeks of unworkable concepts and unwise
abstractions. It was fantastic at the time but that time has come and
gone far, far away. gtk+2.0 is getting old-in-the-tooth and v3 is much
awaited for precisely the same reasons as gtk+2.0 is better than
gtk1.2.

There comes a time in the life of any library, that the codebase simply
cannot stand any more improvements without large amounts of
restructuring and for that restructuring to occur, a SONAME bump must
happen. The code from before the SONAME bump is, by definition, hacked
to the nth degree, it has been patched and poked so many times that the
codebase gets to look like a threadbare carpet. The SONAME bump occurs
for very, very good reasons and the code that arrives after the
transition (although some settling down time might be necessary) is
more coherent, easier to support and easier to continue development
until such time as the next SONAME bump becomes inevitable. Gtk+2.0 has
had more than enough time to settle down after the SONAME bump and has
gained the respect of upstream developers as the most common GUI for
upstream projects written in C (where Qt is probably the same for C++),
as well as picking up bindings for other languages.

This is the reality of library development, not just in free software
but anywhere where the goal is stable, secure, portable code.

I cannot actually believe that you think it is a rational choice to go
backwards to such a horribly mangled codebase as gtk1.2. IMNSHO, the
mere fact that you are even considering this as a viable choice makes
me think that you simply do not understand what is at stake.

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/

Attachment: pgpv2lez5zbgZ.pgp
Description: PGP signature


Reply to: