Re: Use of bin versus libexec
On Wednesday 26 September 2012 10:42:07 Jonathan Marten wrote: > After a lot of discussion, is seems that there are some executables > (as per Thiago's list) that can be moved out. For others > (e.g. Akonadi) it is problematic because there is no standardization > on the location for a "system-wide" libexec as per David's comments > below, so they will have to stay unless a better solution can be > found. > > I'm willing to do some work on those that can be moved, but would it > be acceptable to do such changes (in trunk) at this stage - or would > they have to wait for the next major release (i.e. "KDE 5")? You can't move executables in KDE 4.x, that would break scripts and user's habits. But for the binaries installed by kdelibs, feel free to check out the "frameworks" branch of kdelibs and make the changes there. Use "kde-frameworks" in reviewboard, when submitting patches for review. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5
Re: Use of bin versus libexec
Am 20.09.2012 17:53, schrieb Thiago Macieira: On quinta-feira, 20 de setembro de 2012 16.50.57, Ralf Habacker wrote: kdeinit4 used on windows, need to stay Used by people? Or used by programs and scripts? used by people. On windows there are a few more options intended for command line users see (*). C:\kde\vc100r\git\kdewin-installer-static>kdeinit4 --help Usage: kdeinit4 [options] --help this help page * --list list kde processes * --list-dbus-apps list all applications registered in dbus * --quit-over-dbus quit all application registered in dbus --no-dbus do not start dbus-daemon --no-klauncher do not start klauncher --no-kded do not start kded * --shutdown safe shutdown of all running kde processes first over dbus, then using hard kill * --terminatehard kill of *all* running kde processes Ralf
Re: Use of bin versus libexec
After a lot of discussion, is seems that there are some executables (as per Thiago's list) that can be moved out. For others (e.g. Akonadi) it is problematic because there is no standardization on the location for a "system-wide" libexec as per David's comments below, so they will have to stay unless a better solution can be found. I'm willing to do some work on those that can be moved, but would it be acceptable to do such changes (in trunk) at this stage - or would they have to wait for the next major release (i.e. "KDE 5")? Regards, Jonathan David Faure writes: > We really need a FHS addition for libexec. > Due to the current mess, QStandardPaths::findExe can't look into libexec, so > the only way to find stuff there is to compile the install prefix into the > library (that's what I do in KF5 for now). -- Jonathan Marten http://www.keelhaul.demon.co.uk Twickenham, UK j...@keelhaul.demon.co.uk
Re: Use of bin versus libexec
On 2012-09-20, David Faure wrote: > We really need a FHS addition for libexec. not really. the libexec executables is in general a implementation detail of the given library. We have the rare case in KDE that we actually call other libraries' executables, which is a different thing, and one I have the impression is declining a bit. ..and by sharing libexec locations between unrelated libraries, we get the joys of possible collisions, of executing other libraries implementation details by accident with all the mess that is created by that. /Sune
Re: Use of bin versus libexec
On 09/20/2012 11:53 AM, Thiago Macieira wrote: > On quinta-feira, 20 de setembro de 2012 16.50.57, Ralf Habacker wrote: > kdeinit4 >> >> used on windows, need to stay > > Used by people? Or used by programs and scripts? > > If it's the latter, it can be moved. > The only reason I've ever run kdeinit4 is to get debug logging changes to take effect without logging out completely(i.e after changing settings in kdebugdialog) signature.asc Description: OpenPGP digital signature
Re: Use of bin versus libexec
Hello all. Sorry for messing around here (I'm not a KDE developer) but in case anyone interested in OpenBSD look, I'll try to present it here via some thoughts and facts. 1. OpenBSD doesn't care about FHS, and all *nix except Linux distros do not care either. Because FHS is Linux-only itself. 2. Due to (1) some folders should be placed in other, errrm, places. Particularly, libexec folder for non-base packages should be /usr/local/libexec/, not something in */lib/. Unfortunately, while there exists KDE_LIBEXEC_DIR (if I recall correctly) CMake configuration option, it's ignored in many places. 3. I've patches for stuff in KDE 4.9 that got hardcoded in $KDELIBDIR/kde4/libexec. Runs more or less fine here, but not polished yet. If anyone is interested, I could publish them on review board. 20.09.2012 15:47 пользователь "Jonathan Marten" написал: > There are a lot of executables in $KDEDIR/bin which are used for > internal purposes within KDE and are not intended to be directly > executed by the end user. Having these in the user's $PATH is not > necessary and has overheads for the shell (and for the user, when > doing tab-completion of a command). > > Maybe the forthcoming next major release of KDE (i.e. that based on > Qt5 and Frameworks, whether it ends up being called "KDE 5" or > something else) would be a good time to review what is installed here, > and move anything that is not intended to be run by the user into > $KDEDIR/lib/kde4/libexec? KStandardDirs::findExe() already searches > there (before $PATH or $KDEDIR/bin), so there should be no > serious compatibility problems. > > I could submit bugs for all of the individual components that install > such things, but this message is just to gauge the reaction first. > Here is a quick survey of my current $KDEDIR/bin, I'm not sure about > the purpose of all of these executables but have certainly never had > the occasion to run any of them as a user. Some of them are even > dangerous to run... > > *.kss <-- all screen savers > akonadi_* > akonadiserver > amarok_afttagger > amarokcollectionscanner > curconvd > dtvdaemon > kactivitymanagerd > kalarmautostart > kapplymousetheme > kbuildsycoca4 <-- but useful for the user to run > sometimes > kcheckrunning > kcminit > kcminit_startup > kcookiejar4 > kded4 > kdeinit4 > kdeinit4_shutdown > kdeinit4_wrapper > kdekillall > kdostartupconfig4 > kfilemetadatareader > khotnewstuff-upload > kio_svn_helper > kjotsmigrator > kmail-migrator > kmailcvt > knotify4 > kpartloader > krandrstartup > kres-migrator > ksmserver > kstartupconfig4 > ksysguardd > ktesnippets_editor > ktmagnetdownloader > kuiserver > kwalletd > kwrapper4 > kwrited > lucene2indexer > nepomukindexer > nepomukserver > nepomukservicestub > nspluginscan > plasma-remote-helper > rdfindexer > servicemenudeinstallation > servicemenuinstallation > sopranod > strigidaemon > xmlindexer > > -- > Jonathan Marten http://www.keelhaul.demon.co.uk > Twickenham, UK j...@keelhaul.demon.co.uk >
Re: Use of bin versus libexec
>kdeinit4 used on windows, need to stay
Re: Use of bin versus libexec
David Faure wrote: > On Thursday 20 September 2012 19:36:39 Sune Vuorela wrote: >> On 2012-09-20, Kevin Krammer wrote: >>> Do you mean $PREFIX/libexec, where $PREFIX will often be /usr (for=20 >>> distribution packages)? >> >> that only works in redhat/fedora land. In other distributiotns, like >> debian and ubuntu, libexec is placed in directories under >> prefix/libdir/libraryname/ - e.g. /usr/lib/kde4/libexec or >> /usr/lib/utempter/ > > We really need a FHS addition for libexec. Actually users of libexec are discussing about removing it. See this presentation from this year's DevConf.cz: http://rvokal.fedorapeople.org/devconf2012/harald-A_streamlined_and_fully_compatible_Linux_Files.pdf (from http://fedoraproject.org/wiki/DeveloperConference2012 ) Ciao -- Luigi
Re: Use of bin versus libexec
On Thursday 20 September 2012 19:36:39 Sune Vuorela wrote: > On 2012-09-20, Kevin Krammer wrote: > > Do you mean $PREFIX/libexec, where $PREFIX will often be /usr (for=20 > > distribution packages)? > > that only works in redhat/fedora land. In other distributiotns, like > debian and ubuntu, libexec is placed in directories under > prefix/libdir/libraryname/ - e.g. /usr/lib/kde4/libexec or > /usr/lib/utempter/ We really need a FHS addition for libexec. Due to the current mess, QStandardPaths::findExe can't look into libexec, so the only way to find stuff there is to compile the install prefix into the library (that's what I do in KF5 for now). The problem is that it means one can't move stuff later on. Not sure we need to support that, but it's nice when it's possible (e.g. for cases like cross- compilation). (KF5 currently uses $PREFIX/libdir/kde5/libexec/kioslave, I should s/kde5/kf5/ though) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5
Re: Use of bin versus libexec
On 2012-09-20, Kevin Krammer wrote: > Do you mean $PREFIX/libexec, where $PREFIX will often be /usr (for=20 > distribution packages)? that only works in redhat/fedora land. In other distributiotns, like debian and ubuntu, libexec is placed in directories under prefix/libdir/libraryname/ - e.g. /usr/lib/kde4/libexec or /usr/lib/utempter/ /Sune
Re: Use of bin versus libexec
Kevin Krammer writes: > Do you mean $PREFIX/libexec, where $PREFIX will often be /usr (for > distribution packages)? Yes, that's what I meant - in theory equivalent, since $KDEDIR will be set to the same at runtime. -- Jonathan Marten http://www.keelhaul.demon.co.uk Twickenham, UK j...@keelhaul.demon.co.uk
Re: Use of bin versus libexec
On quinta-feira, 20 de setembro de 2012 16.50.57, Ralf Habacker wrote: > >> >kdeinit4 > > used on windows, need to stay Used by people? Or used by programs and scripts? If it's the latter, it can be moved. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Use of bin versus libexec
On Thursday, 2012-09-20, Jonathan Marten wrote: > Kevin Krammer writes: > > Agreed. It is important, however, to remember that some of those (e.g. > > akonadiserver, akonadi_control) are not KDE programs and can therefore > > not be in a KDE specific libexec location but have to go into a standard > > (FHS or freedesktop.org) location for that purpose. > > Thanks for the clarification Kevin. Perhaps a better place for those > Akonadi executables would then be $KDEDIR/libexec - this location > isn't in the LSB/FHS but many packages which still use GNU Autoconf > use it. IIRC KDE3 had the same. Do you mean $PREFIX/libexec, where $PREFIX will often be /usr (for distribution packages)? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Use of bin versus libexec
Kevin Krammer writes: > Agreed. It is important, however, to remember that some of those (e.g. > akonadiserver, akonadi_control) are not KDE programs and can therefore not be > in a KDE specific libexec location but have to go into a standard (FHS or > freedesktop.org) location for that purpose. Thanks for the clarification Kevin. Perhaps a better place for those Akonadi executables would then be $KDEDIR/libexec - this location isn't in the LSB/FHS but many packages which still use GNU Autoconf use it. IIRC KDE3 had the same. -- Jonathan Marten http://www.keelhaul.demon.co.uk Twickenham, UK j...@keelhaul.demon.co.uk
Re: Use of bin versus libexec
On 2012-09-20, Kevin Krammer wrote: > Agreed. It is important, however, to remember that some of those (e.g.=20 > akonadiserver, akonadi_control) are not KDE programs and can therefore not = > be=20 > in a KDE specific libexec location but have to go into a standard (FHS or=20 > freedesktop.org) location for that purpose. Or in a akonadi specific location... like $prefix/$libdir/akonadistuff/ /Sune
Re: Use of bin versus libexec
On Thursday, 2012-09-20, Thiago Macieira wrote: > On quinta-feira, 20 de setembro de 2012 12.46.47, Jonathan Marten wrote: > > There are a lot of executables in $KDEDIR/bin which are used for > > internal purposes within KDE and are not intended to be directly > > executed by the end user. Having these in the user's $PATH is not > > necessary and has overheads for the shell (and for the user, when > > doing tab-completion of a command). > > Hello Jonathan > > During the 4.0 time, we did move several helper executables into libexec to > free up bin. However, note that some executables remain in bin because they > are often usable by users, including when we request help of them. > > Of course, it's been 5 years and some executables must have crept back in. > > The ones I didn't keep below mean I have no opinion on. > > > akonadi_* > > akonadiserver > > Most of those are never meant to be run directly, including akonadiserver. > I've manually run some of the agents for debugging purpose, but those were > isolated cases and required reading the source code anyway. > > Akonadi is controlled by akonadictl. That's the one that should stay, plus > akonadiconsole. Agreed. It is important, however, to remember that some of those (e.g. akonadiserver, akonadi_control) are not KDE programs and can therefore not be in a KDE specific libexec location but have to go into a standard (FHS or freedesktop.org) location for that purpose. > > kmail-migrator > > kmailcvt > > User facing tool, should maybe stay. One of them, anyway. We'll probably replace kmail-migrator with an explicit import at some point so I wouldn't care about that one. Laurent is also working on a new import program so kmailcvt might go away as well. For the other migrators I think it makes sense to keep them in bin/ in order to be able to run them manually if needed. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Use of bin versus libexec
On quinta-feira, 20 de setembro de 2012 12.46.47, Jonathan Marten wrote: > There are a lot of executables in $KDEDIR/bin which are used for > internal purposes within KDE and are not intended to be directly > executed by the end user. Having these in the user's $PATH is not > necessary and has overheads for the shell (and for the user, when > doing tab-completion of a command). Hello Jonathan During the 4.0 time, we did move several helper executables into libexec to free up bin. However, note that some executables remain in bin because they are often usable by users, including when we request help of them. Of course, it's been 5 years and some executables must have crept back in. The ones I didn't keep below mean I have no opinion on. > akonadi_* > akonadiserver Most of those are never meant to be run directly, including akonadiserver. I've manually run some of the agents for debugging purpose, but those were isolated cases and required reading the source code anyway. Akonadi is controlled by akonadictl. That's the one that should stay, plus akonadiconsole. > kbuildsycoca4 <-- but useful for the user to run sometimes Needs to stay. > kcheckrunning > kcminit > kcminit_startup > kcookiejar4 > kdeinit4_shutdown > knotify4 > kwalletd > kwrited > sopranod > strigidaemon All of the above should be moved. > kded4 > kdeinit4 Not sure. Those are sometimes useful. In the particular case of kded4, if it's moved, it would be nice if kdeinit4_wrapper found it in libexec too. It's useful to restart it sometimes: kquitapp kded kdeinit4_wrapper kded4 > kdeinit4_wrapper > kwrapper4 Need to stay. > kmail-migrator > kmailcvt User facing tool, should maybe stay. One of them, anyway. > ksmserver Should move. No one ever runs this one manually, since it's the only process that you cannot restart in KDE without causing a logout. > ksysguardd Should move, provided ksysguard knows how to find it on remote hosts. > nepomukindexer > nepomukserver > nepomukservicestub Same as akonadi. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Use of bin versus libexec
There are a lot of executables in $KDEDIR/bin which are used for internal purposes within KDE and are not intended to be directly executed by the end user. Having these in the user's $PATH is not necessary and has overheads for the shell (and for the user, when doing tab-completion of a command). Maybe the forthcoming next major release of KDE (i.e. that based on Qt5 and Frameworks, whether it ends up being called "KDE 5" or something else) would be a good time to review what is installed here, and move anything that is not intended to be run by the user into $KDEDIR/lib/kde4/libexec? KStandardDirs::findExe() already searches there (before $PATH or $KDEDIR/bin), so there should be no serious compatibility problems. I could submit bugs for all of the individual components that install such things, but this message is just to gauge the reaction first. Here is a quick survey of my current $KDEDIR/bin, I'm not sure about the purpose of all of these executables but have certainly never had the occasion to run any of them as a user. Some of them are even dangerous to run... *.kss <-- all screen savers akonadi_* akonadiserver amarok_afttagger amarokcollectionscanner curconvd dtvdaemon kactivitymanagerd kalarmautostart kapplymousetheme kbuildsycoca4 <-- but useful for the user to run sometimes kcheckrunning kcminit kcminit_startup kcookiejar4 kded4 kdeinit4 kdeinit4_shutdown kdeinit4_wrapper kdekillall kdostartupconfig4 kfilemetadatareader khotnewstuff-upload kio_svn_helper kjotsmigrator kmail-migrator kmailcvt knotify4 kpartloader krandrstartup kres-migrator ksmserver kstartupconfig4 ksysguardd ktesnippets_editor ktmagnetdownloader kuiserver kwalletd kwrapper4 kwrited lucene2indexer nepomukindexer nepomukserver nepomukservicestub nspluginscan plasma-remote-helper rdfindexer servicemenudeinstallation servicemenuinstallation sopranod strigidaemon xmlindexer -- Jonathan Marten http://www.keelhaul.demon.co.uk Twickenham, UK j...@keelhaul.demon.co.uk
