On Mon, Jul 2, 2012 at 6:53 AM, Lukáš Jirkovský <l.jirkovsky@xxxxxxxxx> wrote: > On 1 July 2012 22:17, Clemens Buchacher <drizzd@xxxxxx> wrote: >> Hi, >> >> I'd like to bring to your attention the discussion surrounding >> gnome-shell/networkmanager bug #679212 (NetworkManager VPN secrets: >> NetworkAgent internal error): >> >> https://bugzilla.gnome.org/show_bug.cgi?id=679212 >> >> A fix for this particular bug is under way. The cause for the bug was >> Arch Linux's use of different libexecdirs for gnome-shell and >> networkmanager plugins (/usr/lib/gnome-shell and >> /usr/lib/networkmanager, respectively), instead of the default >> /usr/libexec. This is in accordance with Arch Packaging Standards: >> >> "Avoid using /usr/libexec/ for anything. Use /usr/lib/${pkgname}/ >> instead." [1] >> >> What is the motivation for this rule? In response to the above bug >> report, a gnome-shell dev says that he "could consider this weird >> libexecdir setting a distribution problem." Since this seems to be an >> unusual setting, I suspect that there might still be many more bugs >> lurking around for which Arch Linux plays beta tester. Indeed, this is >> not the first time that I am having trouble with Arch Linux packages >> using custom installation directories [2]. >> >> Maybe it's not such a big deal and it's just me having some tough luck >> (2 events do not make a good statistic). But expectations upstream seem >> to contradict the Arch Linux rule, so I wanted to bring it up for >> discussion. >> >> Clemens >> >> [1] https://wiki.archlinux.org/index.php/Arch_Packaging_Standards#Package_etiquette >> [2] http://gnu-octave-repository.2306053.n4.nabble.com/geometry-1-4-0-cannot-handle-installation-prefixes-td4463998.html > > > libexec is not part of FHS, so I would say it's gnome guys who should fix that. As far as I know, Fedora/RedHat are the only ones to use this location. Unless I'm mistaken there is a push internally there to stop using it and instead use /usr/lib/<pkgname> like everyone else. Aside from that, it really makes no sense to distinguish between the two folders, it is perfectly possible to have binaries that should belong to both. -t
