Loomio
October 1st, 2013 21:55

Extra issues

Fabian Kosmale
Fabian Kosmale Public Seen by 19

Hi,

there have been a few issues with /extra lately [1]. While the first one has a proposed solution by gcala, it would require us to patch a package OUTSIDE of extra, which is something that I don't really like; and I think it misses somewhat the point of having extra, requiring us to patch software in platform to support GTK applications. I'd like to hear your opinions on this. Personally, I'm not such as a fan of having /extra (the file hierarchy, as opposed to extra the repository), though I don't mind if it stays as long as the linked issues can be resolved. What's your stance on it?

[1]: https://groups.google.com/forum/#!topic/chakra-devel/pDooCTbPSV8 ; https://groups.google.com/forum/#!topic/chakra-ccr/ejuch_e8dfI ; https://groups.google.com/forum/#!topic/chakra-ccr/1QBEBJnOl3g

Ram-Z

Ram-Z October 1st, 2013 22:30

Isn't it possible to extend the search with -DCMAKE_PREFIX_PATH or -DCMAKE_INCLUDE_PATH ?

According to man:
If NO_DEFAULT_PATH is specified, then no additional paths are added to the search. If NO_DEFAULT_PATH is not specified, the search process is as follows:
1. Search paths specified in cmake-specific cache variables. These are intended to be used on the command line with a -DVAR=value. This can be skipped if NO_CMAKE_PATH is passed.
/include for each in CMAKE_PREFIX_PATH
CMAKE_INCLUDE_PATH

Giuseppe Calà

Giuseppe Calà October 2nd, 2013 16:10

@Ram-Z These are all flags I tried with dolphin-emu:

-DCMAKE_INSTALL_PREFIX=/extra/usr
-DGTK2_GDKCONFIG_INCLUDE_DIR=/extra/usr/lib/gtk-2.0/include
-DGTK2_GTK_LIBRARY=/extra/usr/lib
-DGTK2_GTK_INCLUDE_DIR=/extra/usr/include/gtk-2.0
-DGTK2_GDK_INCLUDE_DIR=/extra/usr/include/gtk-2.0
-DGTK2_GDK_LIBRARY=/extra/usr/lib

All was useless. Adding a single line in FindGTK2.cmake solved.

Regarding this discussion: I am in favor ditching /extra prefix and put all gtk apps on regular filesystem, continuing to provide them through [extra].

Imho, having gtk applications in some "isolated" folder doesn't make Chakra gtk-free. The system, especially pacman, knows about them and no one can, f.i., clean /extra folder thinking to purge the system from all gtk stuffs. Pacman would complain (bundle system not suffered of this). The current solution doesn't make Chakra gtk-free but gives trouble to packagers and end users.

So, since "we have to" provide gtk apps, thumb up to deploy them on regular paths.

AlmAck

AlmAck October 3rd, 2013 21:09

This is an interesting story... at the beginning chakra was a pure gtk free distro thanks to the bundles. But as you know many problems arise and to maintain the bundles env. was not easy and time consuming. We decided this year to move our bundles to a real directory /extra. Was a little bit trivial at the beginning but was successfully implemented.
After reading the links above I agree that /extra is not really the best solution, but the idea was to keep the gtk lib and programs separated form the main root.
For me gtk free means:
- I can install, and use chakra without any gtk dependency
- is pure kde
- I'm not fanatic, if some gtk libs resides in my main root folder is not a problem, but I want that the lovely kde env. works flawless with the best optimisation possible.

I think that maybe is time to redefine what chakra is, ok is a gtk free distribution but what is the main goal?
IMHO chakra should be seen not as a "gtk free" but only as a fantastic kde distribution. Almost the 90% of our users use the [extra] repo, for FF or chromium the repository is needed.
To return back to the main discussion, if adding a small patch to cmake fix the issues above, why not? but is only this one? or in the future we need to apply other workarounds?
If this is not the case... well... is time to remove /extra and I agree with Giuseppe.

Btw, the extra pkgs should remain like "bundles", for instance chromium include other 2 pkgs like pepperflash and libpdf.

Michael Haesel

Michael Haesel October 4th, 2013 15:36

I'm unsure, what to do, but reading all of this, I'm in favor to install all Gtk applications to the main root and leave them in extra as an optional repository, which should not be enabled per default. I know, we will mix all these libraries and binaries, but, as AlmAck wrote, if you have enabled the extra repo, you already have all of these files in your filesystem, regardless, if they are in /extra or in your base root.

But still, I'm not completely convinced and if this would be a proposal, I would abstain.

totte

totte October 6th, 2013 14:22

I'd rather see the bundles make a comeback, than this /extra. That said, I'm aware of the technical issues with both solutions and perhaps the simpler choice would be not to make any zealous goals of being GTK "free" but rather focus on developing the premiere KDE GNU/Linux distribution in technical and user experience aspects.

Keep the [extra] repository around and install everything in the standard FHS, but have it remain a lower priority and limited in size compared to KDE and Qt software.

Neofytos Kolokotronis

Neofytos Kolokotronis October 6th, 2013 20:48

As I understand it (with some insight from Fabian), if we keep our buildsystem gtk-free then the loading of the gtk libraries will only occur when the applications that use them are started. So it doesn't matter in the end where the libraries are installed.

If the above is the case, then I don't care much as where the libs are installed, as long as our buildsystem remains gtk-free and we continue providing gtk stuff in the [extra] repo, with a minimum of available apps.

Just a reminder that being gtk-free was not a goal when Chakra first started, but a suggestion from Chakra users that was adopted by the team.
Although I like the idea of gtk-freeness, I don't like how it keeps coming up (as issues rise) and draws our attention away from packaging for other repos/developing tools/KDE SC. Hopefully this will put a stop to it..

Fabian Kosmale

Fabian Kosmale started a proposal October 6th, 2013 21:21

Install GTK applications in the normal place Closed 11:41pm - Saturday 9 Nov 2013

I propose that we install GTK applications from now on in / instead of /extra. This will reduce the number of patches and hacks we need to drag along. Extra as a (disabled-by-default) repository would still be kept alive. Considering that there are some CCR packages that install software in /extra now, we might want to make /extra a symlink to / for a transition period. This change would also need careful communication to prevent outrage in the forum.

Results
Agree - 8
Abstain - 3
Disagree - 0
Block - 0
11 people have voted (0%)
totte

totte
Agree
October 7th, 2013 04:12

I'd prefer bundles, but this solution appears to be the least tedious one.

Francesco Marinucci

Francesco Marinucci
Abstain
October 7th, 2013 08:02

Giuseppe Calà

Giuseppe Calà
Agree
October 7th, 2013 17:25

AlmAck

AlmAck October 7th, 2013 20:05

#totte can you please explain why you liked the bundles? I'm just curious :-)
I will vote later, I would like to think again on this before taking a decision.

AlmAck

AlmAck October 10th, 2013 21:38

@totte: Can you explain better your sentence? I'm interested to know you opinion on the bundles (yes is OT, but is related to the /extra choice)

totte

totte October 13th, 2013 04:35

@almack I meant that I like the idea of keeping applications in closed sandboxes, sort of how I remember it being done in Mac OS X. Though, I understand some of the technical downsides of such an approach (using up a lot of memory loading the same resources over and over again rather than having applications share them). I may be wrong about how it works, but that's my understanding of it. It's like you put the application in a walled garden and it's less likely to cause any system-wide issues compared to if you had it run as we usually do.

Fabian Kosmale

Fabian Kosmale
Agree
October 25th, 2013 20:28

AlmAck

AlmAck
Agree
October 25th, 2013 20:54

Neofytos Kolokotronis

Neofytos Kolokotronis October 25th, 2013 23:08

With current available data, I was gonna +1, but I prefer to wait and hear Manuel’s opinion on this.

Adrian Chaves Fernandez

Adrian Chaves Fernandez
Abstain
October 26th, 2013 09:04

I never really understood what difference it makes to have gtk packages in a separate folder. Without that knowledge, I prefer not to vote either way. But I would be inclined to have GTK packages install normally, just in a different repository.

LA

Lukas Appelhans October 26th, 2013 23:22

Mmh, I'd really like Manu's opinion as well!

Martín González

Martín González
Abstain
October 27th, 2013 11:01

Ryan

Ryan
Agree
October 27th, 2013 19:07

This seems to be the most reasonable solution, removing extra work while keeping Chakra's GTK-free principles intact.

B

BrLi October 29th, 2013 17:38

I think the idea of putting all the gtk packages isolated is that, when things go mad, say, critical security issue occurred, one can remove all the gtk-related stuff by rm -rf , with this idea, we can even put things under $HOME/.local/ and make it work again like bundle system does.(say, extract a tarball downloaded from repo into a fixed root tree, and run it.) But for systemwide usage, I'd suggest /usr/local, as fhs suggest, it is for local-installed packages, and for Chakra, gtk isn't our central consideration, so, put all the things, as well as lib32, there, would make things just work (is a default query directory for include, lib, and/or bin) and less problematic like filesystem-extra and depends.

Ryan

Ryan October 30th, 2013 08:54

@brli Manually removing things like this should be discouraged, as it will confuse the package manager. In my opinion, being able to pacman -Rnscu everything in [extra] should suffice if you want to remove all gtk, and /usr/local should be used only for user-installed local packages, which are not known by the package manager.

B

BrLi November 3rd, 2013 17:17

@george2 I know, just for example =)
yet, if we are going to make it be in normal dir, lots of repackage and pkgbuild refine can be done, in a period.

Ram-Z

Ram-Z November 4th, 2013 16:55

For the sake of simplicity, /usr is the best option. As long as all gtk apps stay in [extra] ofc.

As @george2 already stated, a package manager should NOT install to /usr/local.

Ram-Z

Ram-Z
Agree
November 4th, 2013 16:57

If the userbase doesn't strongly disagree, yes!

And if they do... maybe yes

Neofytos Kolokotronis

Neofytos Kolokotronis
Agree
November 8th, 2013 22:55

Since Manuel did not respond, am upvoting this hoping that it will give an end to the gtk issues and make stuff easier for both the end user and packagers.

Francesco Marinucci

Francesco Marinucci
Agree
November 9th, 2013 10:45

Since we won't loose our gtk-free philosophy, i agree with the proposal

LA

Lukas Appelhans
Abstain
November 9th, 2013 12:07