FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 06-09-2011, 10:14 AM
80
 
Default helper scripts location

Hi,

I'm reviewing osc and osc-source_validators (osc is Opensuse Build
Service CLI, the latter a plugin to the former).
An issue arose about helpers script location:
1) Fedora packaging guidelines suggests helpers *should go*
/usr/libexec for helpers ==> requires patching since osc search
helpers in /usr/lib
since it's not in FHS, it's almost certain that a patch won't be upstream-able
2) FHS explicitely allows shell scripts in /usr/lib
3) FHS doesn't forbid putting them in /usr/share as helpers could be
considered as "arch independent data"

There are recent packages that choose options 2 && 3 (namely, systemd
and dracut).
According to me, guidelines doesn't enforce any of these options, and
choice is left to packager/reviewer appreciation, though you may
distinguish an order of precedence.

So, what's the take of my fellow packagers on that particular matter ?

Best regards,
H.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-10-2011, 04:56 PM
Toshio Kuratomi
 
Default helper scripts location

On Thu, Jun 09, 2011 at 12:14:45PM +0200, 80 wrote:
> Hi,
>
> I'm reviewing osc and osc-source_validators (osc is Opensuse Build
> Service CLI, the latter a plugin to the former).
> An issue arose about helpers script location:
> 1) Fedora packaging guidelines suggests helpers *should go*
> /usr/libexec for helpers ==> requires patching since osc search
> helpers in /usr/lib
> since it's not in FHS, it's almost certain that a patch won't be upstream-able
>
This would be the most proper location on Fedora. Note that many upstreams
do take patches of this sort as long as the libexecdir is settable.
libexecdir is a GNU Coding Standard directory; on Debian or other systems
that disallow /usr/libexecdir, libexecdir gets set to /usr/lib.

http://www.gnu.org/prep/standards/html_node/Directory-Variables.html

> 2) FHS explicitely allows shell scripts in /usr/lib

I don't actually see this. Could you point me to the quote and section?

Additionally, the GNU Coding standards explicitly prohibit this (to be clear
the GNU coding standards are not definitive for Fedora like the FHS is at
this time; I'm including the quotation to show what current best practices
are in this regard):
"""
‘libdir’
The directory for object files and libraries of object code. Do not install
executables here, they probably ought to go in ‘$(libexecdir)’ instead.
"""

At similar weight is the fact that some programs currently violate the GNU
Coding Standard recommendation here. However, I can't think of one of those
off the top of my head that is a unix-y program so those may be more
workaround than paradigm setters.

> 3) FHS doesn't forbid putting them in /usr/share as helpers could be
> considered as "arch independent data"
>
<nod>

> There are recent packages that choose options 2 && 3 (namely, systemd
> and dracut).
> According to me, guidelines doesn't enforce any of these options, and
> choice is left to packager/reviewer appreciation, though you may
> distinguish an order of precedence.
>
> So, what's the take of my fellow packagers on that particular matter ?
>
Preference-wise, I would say $LIBEXECDIR; settable at build time to
/usr/libexec on Fedora-style distros and /usr/lib on Debian-style distros is
the best method here. Since we're talking scripts (architecture
independent), /usr/share may also make sense but I'm not a big fan of it.
If you can find me the piece of FHS that explicitly allows shell scripts in
/usr/lib I can figure out how that compares to using /usr/lib.


-Toshio
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-10-2011, 07:23 PM
Haïkel Guémar
 
Default helper scripts location

Le 10/06/2011 18:56, Toshio Kuratomi a écrit :
>
> I don't actually see this. Could you point me to the quote and section?
>


"/usr/libincludes object files, libraries, and internal binaries that
are not intended to be executed directly by users or shell scripts."
http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA


> Additionally, the GNU Coding standards explicitly prohibit this (to be clear
> the GNU coding standards are not definitive for Fedora like the FHS is at
> this time; I'm including the quotation to show what current best practices
> are in this regard):
> """
> ‘libdir’
> The directory for object files and libraries of object code. Do not install
> executables here, they probably ought to go in ‘$(libexecdir)’ instead.
> """
>
> At similar weight is the fact that some programs currently violate the GNU
> Coding Standard recommendation here. However, I can't think of one of those
> off the top of my head that is a unix-y program so those may be more
> workaround than paradigm setters.
>
good to know

> Preference-wise, I would say $LIBEXECDIR; settable at build time to
> /usr/libexec on Fedora-style distros and /usr/lib on Debian-style distros is
> the best method here. Since we're talking scripts (architecture
> independent), /usr/share may also make sense but I'm not a big fan of it.
> If you can find me the piece of FHS that explicitly allows shell scripts in
> /usr/lib I can figure out how that compares to using /usr/lib.
>
>
> -Toshio
+1

I spent some time yesterday talking with opensuse guys on irc, since
/usr/libexec has not been blessed by FHS, they won't move helpers from
/usr/lib which is FHS-compliant location.
I think that packaging guidelines should clarify this point, either we
enforce the use of /usr/libexec (and current packages should be fixed)
or we explicitely allow /usr/lib and/or /usr/share for helpers.

Personnally, i don't feel like burdening the reviewee with a non-FHS
compliant patch that has little chance to be upstreamed if it's not
mandatory.

H.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-10-2011, 07:40 PM
Nicolas Mailhot
 
Default helper scripts location

Le vendredi 10 juin 2011 21:23 +0200, Hakel Gumar a crit :

> I spent some time yesterday talking with opensuse guys on irc, since
> /usr/libexec has not been blessed by FHS, they won't move helpers from
> /usr/lib which is FHS-compliant location.
> I think that packaging guidelines should clarify this point, either we
> enforce the use of /usr/libexec (and current packages should be fixed)
> or we explicitely allow /usr/lib and/or /usr/share for helpers.

Or better, since the FHS process has been re-started, people that feel
strongly about something not covered by the current FHS version should
just make the effort to push the changes they want in the next FHS
revision.

This way everyone else can just continue to require strict FHS
compliance and not bother with special not-really-documented exceptions


--
Nicolas Mailhot


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-10-2011, 09:07 PM
Toshio Kuratomi
 
Default helper scripts location

On Fri, Jun 10, 2011 at 09:23:54PM +0200, Haïkel Guémar wrote:
> Le 10/06/2011 18:56, Toshio Kuratomi a écrit :
> >
> > I don't actually see this. Could you point me to the quote and section?
> >
>
>
> "/usr/libincludes object files, libraries, and internal binaries that
> are not intended to be executed directly by users or shell scripts."
> http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA
>
Ah -- in your original mesage you said that FHS explicitly blessed /usr/lib
as a place for shell scripts... which is not what this is saying. However,
the description of internal binaries might fit the bill -- the FHS (and
Fedora's usage) of "binaries" is not always consistent. Sometimes it is
equivalent to "object files" and other times it is equivalent to
"executables". If we interpret this as "executable" then I think it works.

Note that this portion of the FHS is in direct conflict with the GNU Coding
standards which explicitly says not to use libdir in this way :-(

>
> > Additionally, the GNU Coding standards explicitly prohibit this (to be clear
> > the GNU coding standards are not definitive for Fedora like the FHS is at
> > this time; I'm including the quotation to show what current best practices
> > are in this regard):
> > """
> > ‘libdir’
> > The directory for object files and libraries of object code. Do not install
> > executables here, they probably ought to go in ‘$(libexecdir)’ instead.
> > """
> >
> > At similar weight is the fact that some programs currently violate the GNU
> > Coding Standard recommendation here. However, I can't think of one of those
> > off the top of my head that is a unix-y program so those may be more
> > workaround than paradigm setters.
> >
> good to know
>
> > Preference-wise, I would say $LIBEXECDIR; settable at build time to
> > /usr/libexec on Fedora-style distros and /usr/lib on Debian-style distros is
> > the best method here. Since we're talking scripts (architecture
> > independent), /usr/share may also make sense but I'm not a big fan of it.
> > If you can find me the piece of FHS that explicitly allows shell scripts in
> > /usr/lib I can figure out how that compares to using /usr/lib.
> >
> >
> > -Toshio
> +1
>
> I spent some time yesterday talking with opensuse guys on irc, since
> /usr/libexec has not been blessed by FHS, they won't move helpers from
> /usr/lib which is FHS-compliant location.
>
Is this stuff a GNU configure compiled program? Or does it have
a different build system? (You could point me at the tarball/review request
and I could take a look).

> I think that packaging guidelines should clarify this point, either we
> enforce the use of /usr/libexec (and current packages should be fixed)
> or we explicitely allow /usr/lib and/or /usr/share for helpers.
>
> Personnally, i don't feel like burdening the reviewee with a non-FHS
> compliant patch that has little chance to be upstreamed if it's not
> mandatory.
>
I just reread the thread where we discussed the pros and cons of libexecdir
and here's the take aways for when and why to use libexecdir:

http://thread.gmane.org/gmane.linux.redhat.fedora.devel/25433/

1) Determine if the program cares about the wordsize of the helpers.
* Are the helper programs mandatorily architecture independent or could
they be arch dependent (ex: It's only convenient to write them in shell,
the helpers could be written in C and compiled instead).
* If it's only convenience, how likely is it that helpers would be written
in a compiled language? Would upstream consider it a bug if someone
wrote a helper in a compiled language?
2.a) If the program does not care about the wordsize, then options are
libexecdir or datadir.
* Of the two, libexecdir is mandatory if architecture-specific helpers are
allowed.
* libexecdir is likely better even if architecture-specific helpers are
not allowed as datadir is for data files and executable code is
something of a stretch to classify that way.
* Finally, see the last bullet of 2.b) for what the ramifications of using
%{_libdir} are and whether that's acceptable in this specific case.
2.b) If the program does care about wordsize, then you need to use %_libdir
which will either be /usr/lib or /usr/lib64 on Fedora. The application
(or config file) will need to be compiled/configured to know which path
to use based on compilation (note that this may require a patch to
upstream as well).
* If the program does not care about wordsize but you put it into
%{_libdir} anyway, you force helpers in separate packages/subpackages to
be packaged arch-specific even though the only difference is the path
pointed to by %{_libdir}. This is a pain but it's something that can
be survived as long as people realize that they have to do this. It
doesn't have as significant an impact if all of the helpers are in the
original package; helpers don't get added to by separate packages.

-Toshio
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-13-2011, 12:18 PM
Lennart Poettering
 
Default helper scripts location

On Fri, 10.06.11 09:56, Toshio Kuratomi (a.badger@gmail.com) wrote:

> > There are recent packages that choose options 2 && 3 (namely, systemd
> > and dracut).
> > According to me, guidelines doesn't enforce any of these options, and
> > choice is left to packager/reviewer appreciation, though you may
> > distinguish an order of precedence.
> >
> > So, what's the take of my fellow packagers on that particular matter ?
> >
> Preference-wise, I would say $LIBEXECDIR; settable at build time to
> /usr/libexec on Fedora-style distros and /usr/lib on Debian-style distros is
> the best method here. Since we're talking scripts (architecture
> independent), /usr/share may also make sense but I'm not a big fan of it.
> If you can find me the piece of FHS that explicitly allows shell scripts in
> /usr/lib I can figure out how that compares to using /usr/lib.

What is the benefit of a separate libexecdir?

I am actually in favour of dropping libexecdir entirely, as I have
trouble seeing what its benefits are.

I also believe the distros should not distiungish themselves in this
place, as there is no value in doing so here. I think the worst solution
is to have each package be configured differently in this regard on the
various distributions.

Why do we have a separate libexecdir on Fedora, and why do we want to
keep it even though everybody else uses libdir?

Lennart

--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-13-2011, 12:41 PM
"Richard W.M. Jones"
 
Default helper scripts location

On Mon, Jun 13, 2011 at 02:18:18PM +0200, Lennart Poettering wrote:
> What is the benefit of a separate libexecdir?

I guess because binaries shouldn't go in the library directory.

Now if you wanted to get rid of the {,/usr}/lib64 nonsense, *that*'s
something we can all get behind ...

Rich.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-13-2011, 12:43 PM
Simo Sorce
 
Default helper scripts location

On Mon, 2011-06-13 at 13:41 +0100, Richard W.M. Jones wrote:
> On Mon, Jun 13, 2011 at 02:18:18PM +0200, Lennart Poettering wrote:
> > What is the benefit of a separate libexecdir?
>
> I guess because binaries shouldn't go in the library directory.
>
> Now if you wanted to get rid of the {,/usr}/lib64 nonsense, *that*'s
> something we can all get behind ...

How would you handle multilib and how would you transition stuff ?

Simo.

--
Simo Sorce * Red Hat, Inc * New York

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-13-2011, 01:16 PM
Lennart Poettering
 
Default helper scripts location

On Mon, 13.06.11 13:41, Richard W.M. Jones (rjones@redhat.com) wrote:

>
> On Mon, Jun 13, 2011 at 02:18:18PM +0200, Lennart Poettering wrote:
> > What is the benefit of a separate libexecdir?
>
> I guess because binaries shouldn't go in the library directory.

But it isn't a library directory. It's a directory for arch-depndendant
stuff, which includes (but is not limited to) libraries.

> Now if you wanted to get rid of the {,/usr}/lib64 nonsense, *that*'s
> something we can all get behind ...

Hmm?

Lennart

--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-13-2011, 01:27 PM
Matthew Garrett
 
Default helper scripts location

On Mon, Jun 13, 2011 at 03:16:45PM +0200, Lennart Poettering wrote:
> On Mon, 13.06.11 13:41, Richard W.M. Jones (rjones@redhat.com) wrote:
>
> >
> > On Mon, Jun 13, 2011 at 02:18:18PM +0200, Lennart Poettering wrote:
> > > What is the benefit of a separate libexecdir?
> >
> > I guess because binaries shouldn't go in the library directory.
>
> But it isn't a library directory. It's a directory for arch-depndendant
> stuff, which includes (but is not limited to) libraries.

It's a directory for arch-dependent stuff that should only exist once on
a system, whereas lib is for arch-dependent stuff that may exist for
multiple architectures on one system. I have no opinion on whether that
distinction is important.

--
Matthew Garrett | mjg59@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 12:59 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org