Hi,
I am preparing a package for submission to Fedora.US/Fedora Extras. This package comes with a couple of demo applications I plan to put into a separate sub-package.
Where to install these applications to on FC? What do Fedora conventions recommend?
IMO, they should not be installed to bindir (/usr/bin), because these applications are "not really useful".
Installing them to datadir (/usr/share) or pkgdatadir (/usr/share/<package>) also does not seem appropriate, because these files are architecture dependent.
Remains $libexecdir/<package>.
Ralf
On Tue, 2004-06-29 at 09:59, Ralf Corsepius wrote:
Hi,
I am preparing a package for submission to Fedora.US/Fedora Extras. This package comes with a couple of demo applications I plan to put into a separate sub-package.
Where to install these applications to on FC? What do Fedora conventions recommend?
IMO, they should not be installed to bindir (/usr/bin), because these applications are "not really useful".
Installing them to datadir (/usr/share) or pkgdatadir (/usr/share/<package>) also does not seem appropriate, because these files are architecture dependent.
Remains $libexecdir/<package>.
Ralf
When you separate out the demos into a subpackage, I think it is OK to put the binaries into /usr/bin, because in this case the package would only be installed by those people interested in the demos, and can easily be removed afterwards.
On Tue, 2004-06-29 at 10:51, Gérard Milmeister wrote:
On Tue, 2004-06-29 at 09:59, Ralf Corsepius wrote:
Hi,
I am preparing a package for submission to Fedora.US/Fedora Extras. This package comes with a couple of demo applications I plan to put into a separate sub-package.
Where to install these applications to on FC? What do Fedora conventions recommend?
IMO, they should not be installed to bindir (/usr/bin), because these applications are "not really useful".
Installing them to datadir (/usr/share) or pkgdatadir (/usr/share/<package>) also does not seem appropriate, because these files are architecture dependent.
Remains $libexecdir/<package>.
$libexec only contains binaries that are never invoked directly, but only through another program. So this is not the correct place to put demos in. If there is a large number of demo apps, you could put them into /usr/lib/<packagename>/demos, so as not to pollute /usr/bin.
On Tue, 2004-06-29 at 10:59, Gérard Milmeister wrote:
On Tue, 2004-06-29 at 10:51, Gérard Milmeister wrote:
On Tue, 2004-06-29 at 09:59, Ralf Corsepius wrote:
Hi,
I am preparing a package for submission to Fedora.US/Fedora Extras. This package comes with a couple of demo applications I plan to put into a separate sub-package.
Where to install these applications to on FC? What do Fedora conventions recommend?
IMO, they should not be installed to bindir (/usr/bin), because these applications are "not really useful".
Installing them to datadir (/usr/share) or pkgdatadir (/usr/share/<package>) also does not seem appropriate, because these files are architecture dependent.
Remains $libexecdir/<package>.
$libexec only contains binaries that are never invoked directly, but only through another program. So this is not the correct place to put demos in.
Hmm, I see that using $libdir/<package> could be an approach, but ..
According to the FHS similar considerations as you outline for $libexecdir apply to /usr/lib [http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE22]
Using libdir also seems to be questionable with respect to the GNU Standards, which say [http://www.gnu.org/prep/standards_54.html#SEC54]: `libdir' The directory for object files and libraries of object code. Do not install executables here, they probably ought to go in `$(libexecdir)' instead.
However, both standards leave room for interpretation. The GNU Standards don't cover $libdir/<subdir> and the FHS seems to leave room about their understanding on "users" (Normal users normal don't execute demos, developers will, and do expect to find demos at odd places).
Does anybody know what other Linux distributors do?
If there is a large number of demo apps, you could put them into /usr/lib/<packagename>/demos, so as not to pollute /usr/bin.
That's exactly what I am trying to do. I don't want to pollute /usr/bin with several dozens of tiny demos (ca. 100).
Ralf
Hi Ralf,
Installing them to datadir (/usr/share) or pkgdatadir (/usr/share/<package>) also does not seem appropriate, because these files are architecture dependent.
A find will show you that most packages that ship demos store these in /usr/share/<package>. Maybe not correct, but at least common practice.
Leonard.
On Tue, 2004-06-29 at 10:59, Ralf Corsepius wrote:
IMO, they should not be installed to bindir (/usr/bin), because these applications are "not really useful".
My .02€: If they're in a -demo or -samples subpackage, IMO it's fine to install them to /usr/bin. The package name should be a strong enough hint that it contains "not really useful" stuff; people not wanting that can just skip installing the subpackage or erase after trying it out.
On Tue, 2004-06-29 at 18:17, Ville Skyttä wrote:
On Tue, 2004-06-29 at 10:59, Ralf Corsepius wrote:
IMO, they should not be installed to bindir (/usr/bin), because these applications are "not really useful".
Are these binaries from code examples for some library or similar? If yes, it might make better sense not to include the binaries, but only the source code in /usr/share/doc/<package-name>-demos-<ver> and make sure there is a functioning Makefile to build the binaries, i.e. allow the user to 'cp -a /usr/share/doc/<package-name>-demos-<ver> .' and then make.
On Tue, 2004-06-29 at 18:36, Gérard Milmeister wrote:
On Tue, 2004-06-29 at 18:17, Ville Skyttä wrote:
On Tue, 2004-06-29 at 10:59, Ralf Corsepius wrote:
IMO, they should not be installed to bindir (/usr/bin), because these applications are "not really useful".
Are these binaries from code examples for some library or similar?
Yes. Most of them are coding examples for a library, very few of them are actual "usable sample applications".
If yes, it might make better sense not to include the binaries, but only the source code in /usr/share/doc/<package-name>-demos-<ver> and make sure there is a functioning Makefile to build the binaries, i.e. allow the user to 'cp -a /usr/share/doc/<package-name>-demos-<ver> .' and then make.
I had considered this, but implementing this would require substantial effort (The package uses a bizarre and complex GNUmakefile system and supports building the example code only as part of the complete source-tree.)
Meanwhile I have checked what Debian does with this particular package: * They do not ship the coding examples * They install the sample-applications to /usr/lib/<package>
Ralf
On Tue, 29 Jun 2004, Ralf Corsepius wrote:
On Tue, 2004-06-29 at 18:36, Gérard Milmeister wrote:
On Tue, 2004-06-29 at 18:17, Ville Skyttä wrote:
On Tue, 2004-06-29 at 10:59, Ralf Corsepius wrote:
IMO, they should not be installed to bindir (/usr/bin), because these applications are "not really useful".
Are these binaries from code examples for some library or similar?
Yes. Most of them are coding examples for a library, very few of them are actual "usable sample applications".
If yes, it might make better sense not to include the binaries, but only the source code in /usr/share/doc/<package-name>-demos-<ver> and make sure there is a functioning Makefile to build the binaries, i.e. allow the user to 'cp -a /usr/share/doc/<package-name>-demos-<ver> .' and then make.
I had considered this, but implementing this would require substantial effort (The package uses a bizarre and complex GNUmakefile system and supports building the example code only as part of the complete source-tree.)
Meanwhile I have checked what Debian does with this particular package:
- They do not ship the coding examples
- They install the sample-applications to /usr/lib/<package>
My +1 for /usr/lib/<package> in general for small demo applications, depending on the case /usr/bin can be ok as well if the demos are in separate package.
I'd still put the coding examples to -devel package under documentation, doesn't matter if it compiles there or not, it's often useful just to see some sample code for a given library even if you can't compile it where it is.
- Panu -
devel@lists.stg.fedoraproject.org
-
Gérard Milmeister -
Leonard den Ottolander -
Panu Matilainen -
Ralf Corsepius -
Ville Skyttä