[arch-dev-public] Removing glib 1, gtk 1 and qt3 - Arch-dev-public - lists.archlinux.org

newer
[arch-dev-public] Integrity Check...

[arch-dev-public] Removing glib 1, gtk 1 and qt3

older
[arch-dev-public] Signoff report...

Jan Alexander Steffens

21 May 2013 21 May '13

11:12 a.m.

Greetings everypony, Can we throw out glib 1, gtk 1 and qt3? These are seriously legacy libraries. Check "pactree -rs glib" and "pactree -rs qt3" for dependent packages. Cheers, Jan

Show replies by date

Eric Bélanger

22 May 22 May

2:20 p.m.

On Tue, May 21, 2013 at 7:12 AM, Jan Alexander Steffens < jan.steffens@gmail.com> wrote:

Greetings everypony,

Can we throw out glib 1, gtk 1 and qt3? These are seriously legacy libraries.

Check "pactree -rs glib" and "pactree -rs qt3" for dependent packages.

Cheers, Jan

Well gtk is a depends for imlib wich is required by fvwm, the WM I use. Unless imlib can work without gtk, I give a big -1 to removing glib/gtk from the repo. Beside the fact that they are old, is there any reason to remove them from the repo? I maintain these threee packages and they are working well (no bug assigned). I don't see why they should be removed especially since many apps still depends on them. Eric

Andrea Scarpino

2:33 p.m.

On Wednesday 22 May 2013 10:20:42 Eric Bélanger wrote:

Beside the fact that they are old, is there any reason to remove them from the repo? I maintain these threee packages and they are working well (no bug assigned). I don't see why they should be removed especially since many apps still depends on them.

I'd like to get rid of those libraries too, but Eric maintain them and this is enough. -- Andrea Arch Linux Developer

Tom Gundersen

23 May 23 May

4:34 a.m.

On Wed, May 22, 2013 at 10:33 PM, Andrea Scarpino wrote:

On Wednesday 22 May 2013 10:20:42 Eric Bélanger wrote:

...
Beside the fact that they are old, is there any reason to remove them from the repo? I maintain these threee packages and they are working well (no bug assigned). I don't see why they should be removed especially since many apps still depends on them.

I'd like to get rid of those libraries too, but Eric maintain them and this is enough.

I agree. If ever they start causing problems we could revisit the issue. -t

Allan McRae

4:41 a.m.

On 23/05/13 00:20, Eric Bélanger wrote:

On Tue, May 21, 2013 at 7:12 AM, Jan Alexander Steffens < jan.steffens@gmail.com> wrote:

...
Greetings everypony,

Can we throw out glib 1, gtk 1 and qt3? These are seriously legacy libraries.

Check "pactree -rs glib" and "pactree -rs qt3" for dependent packages.

Cheers, Jan

Well gtk is a depends for imlib wich is required by fvwm, the WM I use. Unless imlib can work without gtk, I give a big -1 to removing glib/gtk from the repo.

Beside the fact that they are old, is there any reason to remove them from the repo? I maintain these threee packages and they are working well (no bug assigned). I don't see why they should be removed especially since many apps still depends on them.

Do many apps really still depend on qt3? I though even Debian managed to go qt3 free in the latest release... Allan

Eric Bélanger

7:16 a.m.

On Thu, May 23, 2013 at 12:41 AM, Allan McRae wrote:

On 23/05/13 00:20, Eric Bélanger wrote:

...
On Tue, May 21, 2013 at 7:12 AM, Jan Alexander Steffens < jan.steffens@gmail.com> wrote:

...
Greetings everypony,

Can we throw out glib 1, gtk 1 and qt3? These are seriously legacy libraries.

Check "pactree -rs glib" and "pactree -rs qt3" for dependent packages.

Cheers, Jan

Well gtk is a depends for imlib wich is required by fvwm, the WM I use. Unless imlib can work without gtk, I give a big -1 to removing glib/gtk from the repo.

Beside the fact that they are old, is there any reason to remove them from the repo? I maintain these threee packages and they are working well (no bug assigned). I don't see why they should be removed especially since many apps still depends on them.

Do many apps really still depend on qt3? I though even Debian managed to go qt3 free in the latest release...

Allan

A dozen. Then you have kdelibs3 and pyqt3 which are also dependencies of other packages. So we're probably talking about 20 qt3 packages.

Andrea Scarpino

4:45 p.m.

On Thursday 23 May 2013 14:41:05 Allan McRae wrote:

Do many apps really still depend on qt3? I though even Debian managed to go qt3 free in the latest release...

I guess many of them could be already removed, e.g.: * kovpn, NetworkManager (both the plasmoid and the applet) support OpenVPN. * qtcurve-qt3, it just a theme which doesn't require many resources to be built. Someone have a development version for Qt4/KDE4 * ksniffer, (and I bet everyone uses wireshark). * ktechlab Others have better alternatives: * kleansweep, bleachbit? (uses PyGTK) sweeper? (maybe miss some feature, just report the feature request to the kde bug tracker) * pwmanager, kwallet? I can't do a detailed list ATM, but I'd like to hear some opinion from the people that use those programs first. I'm in favor or removing gtk1/qt3, but building qt3 takes sooo much time. I really want to drop it when nobody really needs it. -- Andrea Arch Linux Developer

Thomas Bächler

24 May 24 May

8:37 a.m.

Am 23.05.2013 18:45, schrieb Andrea Scarpino:

I guess many of them could be already removed, e.g.: * kovpn, NetworkManager (both the plasmoid and the applet) support OpenVPN.

NetworkManager's OpenVPN support is broken by design and has always been. That said, kovpn is broken, too.

Andrea Scarpino

9:17 a.m.

On Friday 24 May 2013 10:37:31 Thomas Bächler wrote:

NetworkManager's OpenVPN support is broken by design and has always been. That said, kovpn is broken, too.

Could you argument that? I use a OpenVPN network everyday with no issue. -- Andrea Arch Linux Developer

Thomas Bächler

9:27 a.m.

Am 24.05.2013 11:17, schrieb Andrea Scarpino:

On Friday 24 May 2013 10:37:31 Thomas Bächler wrote:

...
NetworkManager's OpenVPN support is broken by design and has always been. That said, kovpn is broken, too.

Could you argument that? I use a OpenVPN network everyday with no issue.

Networkmanager's OpenVPN plugins connects to OpenVPN servers and receives routes and addresses. It then decides to ignore all routing information the server sent and always sets up a default route through the VPN. It also takes some arbitrary host as gateway, not the one that the server tells it to. In this scenario, it is no longer sufficient to configure the server properly, you also need to duplicate all configuration in the networkmanager applet on the client. It's been that way for years and this hasn't changed since (although the last version I tried was a year ago or so).

Andrea Scarpino

9:43 a.m.

On Friday 24 May 2013 11:27:16 Thomas Bächler wrote:

Networkmanager's OpenVPN plugins connects to OpenVPN servers and receives routes and addresses. It then decides to ignore all routing information the server sent and always sets up a default route through the VPN. It also takes some arbitrary host as gateway, not the one that the server tells it to. In this scenario, it is no longer sufficient to configure the server properly, you also need to duplicate all configuration in the networkmanager applet on the client. It's been that way for years and this hasn't changed since (although the last version I tried was a year ago or so).

I had those issue too, but you can set pretty much everything related to routes in the "IP4 Settings -> Routes"[1] tab. Specially the "Ignore automatically obtained routes" option. Back on topic, we can drop at least kovpn then (CC'ing Sergej). [1] http://wstaw.org/m/2013/05/24/plasma-desktopQ10566.png -- Andrea Arch Linux Developer

Thomas Bächler

9:54 a.m.

Am 24.05.2013 11:43, schrieb Andrea Scarpino:

On Friday 24 May 2013 11:27:16 Thomas Bächler wrote:

...
Networkmanager's OpenVPN plugins connects to OpenVPN servers and receives routes and addresses. It then decides to ignore all routing information the server sent and always sets up a default route through the VPN. It also takes some arbitrary host as gateway, not the one that the server tells it to. In this scenario, it is no longer sufficient to configure the server properly, you also need to duplicate all configuration in the networkmanager applet on the client. It's been that way for years and this hasn't changed since (although the last version I tried was a year ago or so).

I had those issue too, but you can set pretty much everything related to routes in the "IP4 Settings -> Routes"[1] tab. Specially the "Ignore automatically obtained routes" option.

This is OT, but I still feel I need to bring this across: The point is that you shouldn't need to configure anything at all - and when you use OpenVPN directly, you don't need to. It's only networkmanager's incorrect defaults that make this more complicated than it should be.

Back on topic, we can drop at least kovpn then (CC'ing Sergej).

[1] http://wstaw.org/m/2013/05/24/plasma-desktopQ10566.png

Yes, let's drop kovpn.

Laurent Carlier

10:52 a.m.

Le vendredi 24 mai 2013 11:43:29 Andrea Scarpino a écrit :

On Friday 24 May 2013 11:27:16 Thomas Bächler wrote:

...
Networkmanager's OpenVPN plugins connects to OpenVPN servers and receives routes and addresses. It then decides to ignore all routing information the server sent and always sets up a default route through the VPN. It also takes some arbitrary host as gateway, not the one that the server tells it to. In this scenario, it is no longer sufficient to configure the server properly, you also need to duplicate all configuration in the networkmanager applet on the client. It's been that way for years and this hasn't changed since (although the last version I tried was a year ago or so).

I had those issue too, but you can set pretty much everything related to routes in the "IP4 Settings -> Routes"[1] tab. Specially the "Ignore automatically obtained routes" option.

Back on topic, we can drop at least kovpn then (CC'ing Sergej).

[1] http://wstaw.org/m/2013/05/24/plasma-desktopQ10566.png

There is also the package qcad[1] that could be updated to v3.0.14, which depends on qt4 [1] https://www.archlinux.org/packages/community/i686/qcad -> https://github.com/qcad/qcad/tree/v3.0.14.0 https://github.com/qcad/qcad/tree/v3.1.0.2 -- Laurent Carlier ArchLinux Trusted User http://www.archlinux.org

Alexander Rødseth

23 May 23 May

10:02 a.m.

Hi, 2013/5/22 Eric Bélanger :

Well gtk is a depends for imlib wich is required by fvwm, the WM I use.

fvwm compiles without imlib and thus without gtk1 (As a former fvwm user, for years, I can recommend pekwm or i3 instead). +1 for moving old cruft to AUR -- Sincerely, Alexander Rødseth xyproto / TU

Eric Bélanger

2:51 p.m.

On Thu, May 23, 2013 at 6:02 AM, Alexander Rødseth wrote:

Hi,

2013/5/22 Eric Bélanger :

...
Well gtk is a depends for imlib wich is required by fvwm, the WM I use.

fvwm compiles without imlib and thus without gtk1

I got an email from a Gentoo dev (Samuli Suominen) : "imlib1 can work without gtk1, that's how we build imlib1 in Gentoo some years ago, there was only a handful of libraries making use of the gtk1 parts of imlib1 and those got thrown out of the portage tree i would be suprised if there was anything left in archlinux just build imlib1 without gtk1" So we could build imlib without gtk. I'll probably do that change regardless of the fate of gtk (unless we also want to get rid of imlib). Given this new information, I'll change my -1 vote to a 0. I can continue to maintain them as long as the maintenance is minimal. But if people want to remove them, then I won't oppose. Also, do all the packages depending on glib/qt3 have a maintainer? We could certainly remove the orphaned ones.

(As a former fvwm user, for years, I can recommend pekwm or i3 instead).

+1 for moving old cruft to AUR

-- Sincerely, Alexander Rødseth xyproto / TU

Thomas Bächler

3:45 p.m.

Am 22.05.2013 16:20, schrieb Eric Bélanger:

Beside the fact that they are old, is there any reason to remove them from the repo? I maintain these threee packages and they are working well (no bug assigned). I don't see why they should be removed especially since many apps still depends on them.

I have another example (not in our repos): http://surf.sourceforge.net/ requires gtk1 and that won't change. I'd prefer having binaries for gtk as opposed to compiling it myself. The gtk package did not need a recompile in over a year, so I see no harm there. The maintenance burden of qt3 and kdelibs3 is probably much higher, and I got rid of them by now, so I don't really care there.

Giovanni Scafora

22 May 22 May

2:24 p.m.

Il 21/05/2013 13:12, Jan Alexander Steffens ha scritto:

Greetings everypony,

Can we throw out glib 1, gtk 1 and qt3? These are seriously legacy libraries.

Check "pactree -rs glib" and "pactree -rs qt3" for dependent packages.

Cheers, Jan

I give a big -1 to removing glib 1, gtk 1 and qt3 from the repo. -- Arch Linux Developer http://www.archlinux.org http://www.archlinux.it

Tom Gundersen

23 May 23 May

4:32 a.m.

On Wed, May 22, 2013 at 10:24 PM, Giovanni Scafora wrote:

Il 21/05/2013 13:12, Jan Alexander Steffens ha scritto:

...
Greetings everypony,

Can we throw out glib 1, gtk 1 and qt3? These are seriously legacy libraries.

Check "pactree -rs glib" and "pactree -rs qt3" for dependent packages.

Cheers, Jan

I give a big -1 to removing glib 1, gtk 1 and qt3 from the repo.

Why? -t

Giovanni Scafora

3:29 p.m.

Il 23/05/2013 06:32, Tom Gundersen ha scritto:

Why?

For the same reasons written by Eric. -- Arch Linux Developer http://www.archlinux.org http://www.archlinux.it

Gaetan Bisson

4:14 p.m.

[2013-05-23 17:29:28 +0200] Giovanni Scafora:

Il 23/05/2013 06:32, Tom Gundersen ha scritto:

...
Why?

For the same reasons written by Eric.

We all can read Eric's emails just fine... -- Gaetan

Giovanni Scafora

4:19 p.m.

Il 23/05/2013 18:14, Gaetan Bisson ha scritto:

[2013-05-23 17:29:28 +0200] Giovanni Scafora:

...
Il 23/05/2013 06:32, Tom Gundersen ha scritto:

...
Why?

For the same reasons written by Eric.

We all can read Eric's emails just fine...

and then? I know very well that you can all read the Eric's emails... I just answered the Tom's question. -- Arch Linux Developer http://www.archlinux.org http://www.archlinux.it

3989

Age (days ago)

3992

Last active (days ago)

Download

20 comments

10 participants

tags

participants (10)

Alexander Rødseth
Allan McRae
Andrea Scarpino
Eric Bélanger
Gaetan Bisson
Giovanni Scafora
Jan Alexander Steffens
Laurent Carlier
Thomas Bächler
Tom Gundersen