Is it possible to setup automake to install a file under a different name? For instance, let's say I have a LICENSE file in my package, which I want to be installed under /usr/share/licenses/mypackage. Is it possible to extend the code below, so that the LICENSE file is installed as "mypackage"?
licensedir = $(datadir)/licenses
license_DATA = LICENSE
I've been googling on this for quite some time now, but didn't find anything useful.
A possible solution is to add an install hook:
install-data-hook:
cd $(DESTDIR)$(datadir)/licenses; \
mv LICENSE mypackage
Related
So I have a Yocto build and I need to install this 3rd party RPM. I've created a recipe for it using the link to the source RPM. Problem is when implementing the do_install() function.
I need to install it, and it's installed via rpm --install rpm_package, and then I need to enable the service.
For the service I know I have to inherit systemd in my recipe file, but for the installation I'm still confused.
The install command only creates directories and copies files over.
Any help is appreciated.
Indeed do_install only create install directories in your /tmp/work/cortex[...]/my_recipe_name/ directory
Normally if you bitbake your image which include your recipe you should have a warning like:
Files/directories were installed but not shipped in any package
So, after the installation you need to "package them" in order to be in your final linux image, to do so use FILES_$PN like below for instance:
FILES_${PN}_append = " /usr/sbin/"
where /usr/bin is the directory which contain what you want to "install" in your image.
Then the package will be shipped in your final image.
For the service, indeed inherit systemd is mandatory + you have to add in do_install
install -Dm0644 ${WORKDIR}/my_script.service ${D}${systemd_system_unitdir}/my_script.service
and at the end of your .bbfile
SYSTEMD_SERVICE_${PN} = "my_script.service"
You can install packages at runtime with rpm, but it is not recommended for production builds, as that is the whole idea behind Yocto which is creating a custom distribution with all your needs integrated.
In order to use rpm command in runtime you need to configure it to fetch the sources from the right location. And the right location is generally a Yocto build, because it is compatible with your board's architecture and system (Otherwise, you need to handle that manually).
You can link the Yocto build rpm files to the board's rpm command using smart, for more info check first the official Yocto documentation here.
Also, you can check more example here and here.
IMPORTANT
I do not recommend creating a systemd/sysvinit service to install an rpm/deb/ipk/tar package.
The idea is, if you install a package with rpm it means that it is already supported by Yocto and has a recipe. So, simply:
IMAGE_INSTALL_append = " package"
I am building binaries for our custom board(iMX7) using Yocto-morty. I need some libraries such as UTF-32.so, UTF-16.so, UTF-7.so from glibc package for bluetooth file tranfer. But these libraries are not available in the rootfs, only files available under /usr/lib/gconv are gconv-modules and ISO8859-1.so. So I am trying to add these libraries by adding new bbappend file glibc_2.24.bbappend with the following content
FILES_${PN} += "${libdir}/gconv/*"
do_install_locale_append() {
cp -r ${dest}${libdir}/gconv ${D}${libdir}/
}
But it results in the following error:
ERROR: glibc-2.24-r0 do_populate_sysroot: The recipe glibc is trying to install files into a shared area when those files already exist. Those files and their manifest location are:
build_dir/tmp/sysroots/esomimx7d/usr/lib/gconv/ISO-2022-CN.so Matched in b'manifest-esomimx7d-glibc-locale.populate_sysroot'
build_dir/tmp/sysroots/esomimx7d/usr/lib/gconv/ARMSCII-8.so Matched in b'manifest-esomimx7d-glibc-locale.populate_sysroot'
......
Then I tried to remove the glibc-locale from the image but due to some dependency issues I could not do that.
Could anyone help me to add the above mentioned libraries to the rootfs?
The error is telling you the answer to your problem. Those files are part of the glibc-locale recipe, so you just need to install the right packages into the rootfs.
$ oe-pkgdata-util find-path \*/UTF-7.so
glibc-gconv-utf-7: /usr/lib/gconv/UTF-7.so
So you need to add glibc-gconv-utf-7 (or -utf-32, etc) to your image.
You can remove thm and compile again it will work.
rm build_dir/tmp/sysroots/esomimx7d/usr/lib/gconv/ISO-2022-CN.so
rm build_dir/tmp/sysroots/esomimx7d/usr/lib/gconv/ARMSCII-8.so
This is for work around only we need for perminant sol.
These files are belongs to glibc-locale so you need to install the required packages.
$ oe-pkgdata-util find-path */UTF-7.so
glibc-gconv-utf-7:> /usr/lib/gconv/UTF-7.so
Add the glibc-gconv-utf-7 (or -utf-32, etc) to recipe image(e.g core-image-minimal).
This question has been asked many time but I am not able to resolve the problem from them so I am asking
I had installed Cygwin a few days ago.I tried using ./configure command but it says
-bash: ./configure: No such file or directory
I tried using
where configure
but I got the output
INFO: Could not find files for the given pattern(s).
then I tried grep configureand I got this output
/etc/bash_completion.d/configure
/usr/i686-pc-cygwin/sys-root/usr/share/libtool/libltdl/configure
/usr/share/ELFIO/configure
/usr/share/libtool/libltdl/configure
I tried to export the path and then run the ./configure but it also didn't worked.
I find no executable file named as configure in my cygwin bin directory.
Does it mean that I have to add configure file manually?How can I correct it?
NOTE :- I had also tried sh configure but it also didn't worked
If a software project is set up to be built using autoconf, that tool generates a script canonically called configure. It queries the system for various parameters that are subsequently used in the build, and is specific to the software package to be built. Different software projects have different configure scripts. They are all called configure, but their contents are not the same.
So, to actually build such a software project once that script was set up (usually done by the maintainers when packaging the source tarball for distribution), you call:
tar xzf <tarball>.gz # or xjf <tarball>.bz2 or whatever
cd <sourcedir> # the one you just untarred
./configure
make
make install
Note the prefix ./, which means "located in this directory" (i.e. the top directory of that project's source tree).
Actually, the better procedure is the so-called "out-of-tree build", when you set up a different directory for the binaries to be built in, so the source tree remains unmodified:
tar xzf <tarball>.gz # or xjf <tarball>.bz2 or whatever
mkdir builddir
cd builddir
../<sourcedir>/configure
make
make install
So, there is supposed to be no configure executable in your PATH, you are supposed to call the script of that name from the source tree you are trying to build from.
If I correctly understood...
Configure is not an application that should be installed on your system, but script that should be delivered with source code to prepare for make command. File named configure should be in the main directory of source code.
I understand that this is an old question. However many might find this solution helpful.
Normally we use the make command to compile a downloaded source in cygwin. In many cases it contains a autogen.sh file. Running that file with
bash autogen.sh
will in many case solve the problem. At least it solved my issue and i could then use the make command
What: I've a shell script that I'd like to distribute to my LUG.
I believe that a debian package will be the easiest way to distribute it. I want to create a .deb file for the script in this repository
Where: I want it to be placed in some directory like /usr/local/bin so that it is easy to execute and maybe create some symbolic links
Problem: How to write make file for it and/or other files and folders required to do that. I researched a lot when I tried to do it couple of months ago but no luck then. Here are the files from my previous attempt Now I'm trying to pack this for a tutorial on shell script in my LUG and facing similar situation again.
I'll be really glad if someone can be patient enough to guide me through it.
Any kind of resources or details will be much appreciated.
PS: I also intend to port the script to perl soon.
As mirabilos said, you should at least have a look to the packaging-tutorial written by Lucas Nussbaum, the current Debian Project Leader. You can install it directly from a Debian repository:
# apt-get install packaging-tutorial
Then, open and skim the PDF located at /usr/share/doc/packaging-tutorial/packaging-tutorial.pdf. After skimming it you'll have the basic knowledge needed to understand the structure of a Debian package.
Now let's get our hands dirty. mv your script to a new directory. The name of the directory must follow the nomenclature upstreamname-*version*.
rul#helicon:/tmp/a$ mkdir script-0.1
rul#helicon:/tmp/a$ mv script.sh script-0.1
cd to the directory where your script is and run dh_make --createorig. Choose single binary. You'll now have a debian/ directory with lots of file in it. This files are the ones you need to make your package. In your case, most, if not all, of the *.ex files are safe to be removed. Read and modify when needed the remaining files.
Now let's write the core of our package. You want to install a script in /usr/local/bin. The good news is that there is already a program that does that for you. You just have to specify the file name and where to put it. This program is dh_install. It has a very complete man page. After reading it, you should now understand that you have to create a install file in the debian/ directory.
rul#helicon:/tmp/a/script-0.1$ echo "script.sh usr/local/bin/" > debian/install
Here you have a real example of this file usage.
That's it! You have all you need to build your package. cd to the root directory of your package and run dpkg-buildpackage. If all went well, you'll have your fresh new .deb in ../.
You really should have a look at, in this order, the inofficial packaging tutorial, the Debian New Maintainers' Guide, Debian Developer's Reference and Policy. (The order is also increasingly dry, and reversed for formalness.)
It may take two days or so, but is really worth it.
Also, look at other small packages shipping only scripts, or other mere “file installers” (like php-htmlpurifier, first example I remembered while writing this).
If your package will only have a single file (or small number of files) in it, going through the full Debian toolchain might be overkill.
For packaging single files, I recommend you use the equivs tool. Install the equivs package, then run equivs-control to create a template file.
Edit the template file (give your package a name, version number etc.).
Add the name of your script to the Files: attribute in the template, for example:
Package: my-awesome-script
Version: 4.2
Files: my-awesome-script.sh /usr/local/bin
Section: misc
Priority: optional
Standards-Version: 3.9.2
Maintainer: Me <me#gmail.com>
Description: An awesome script doing stuff
Lorem ipsum etc. pp.
Put the script file alongside the template file.
Run equivs-build which will create your Debian package.
This is much easier for these simple cases than anything else – and the package that you get is standards compliant without resorting to any hacks or jumping through hoops.
for pre install, write your script in file DEBAIN/preinst;
for post install, write your script in file DEBAIN/postinst;
Use checkinstall or fpm to build your packages in minutes not hours or days!:
sudo checkinstall --fstrans=yes --install=no -D --pkgname=script \
--maintainer='Name <name#domain.tld>' --pkgarch=all --pkgversion=0.1 \
--nodoc cp script.sh /usr/local/bin
fpm -s dir -t deb --prefix /usr/local/bin -n script -v 0.1 -a all ./script.sh
Note: checkinstall requires dpkg/dpkg-deb (only works on Debian/Ubuntu), fpm is platform independent but requires ruby.
Is there a way to get a list of filenames/paths that make install copies to the filesystem? Some packages come with a MANIFEST file, but not the ones that I am working with.
I was just investigating this myself while compiling a custom version of QEMU. I used the following method to work out what was installed and where (as well as using it as a basis for a .deb file):
mkdir /tmp/installer
./configure --target-list=i386-softmmu
make
sudo make install DESTDIR=/tmp/installer
cd /tmp/installer
tree .
Tree is a utility that recursively displays the contents of a directory in a visually appealing manner - sudo apt-get install tree for Debian / Ubuntu users
Hope that helps someone... it took me a bit of poking around to nut it out, but I found it quite a useful way of visualising what was going on.
The most fool-proof way is to use chroot: have "make install" run inside a chroot jail; compute a list of the files that you had before the installation, and compare that to the list of files after the installation.
Many installations will support either a --prefix configuration option, and/or a DESTDIR environment variable. You can use those for a lighter-wait version of chroot (trusting that the installation will fail if it tries to write to a location outside these if you run installation as a fairly unprivileged user).
Another approach is to replace the install program. Many packages support an INSTALL environment variable that, well, is the install program to use; there are tracing versions of install around.
make uninstall might show the files as it removes them if the author of the compiling instructions provides the information to allow an uninstall (it has been awhile since I have done one so I can't say for sure).
Also make -n install will do a "dry run" of the install process and it may be reasonable to extract the information from its results.
It differs for every project that you run 'make install' on. The files which are installed are controlled by the install target in the Makefile being used. Your best bet is to open the Makefile and search for 'install:' - from there you can see what files will be copied out to your system.
Take a snapshot of the contents of the install location before installing
Install
Compare the current contents with the old contents.
Example:
./configure --prefix /usr/local
make -j`nproc`
find /usr/local | sort -u > /tmp/snapshot1
make install
find /usr/local | sort -u > /tmp/snapshot2
comm -3 /tmp/snapshot{1,2} # this prints the files added by `make install` to stdout
If the install program you're using doesn't support DESTDIR or --prefix (or an equivalent), I have found that it may be possible to identify new files as follows:
Start with as clean a system as possible (a fresh VM image is preferable)
Compile the software, wait a few minutes.
Install the software package.
Find files modified within the past 5 minutes: sudo find / -mmin -5 -type f (the find command has a ton of parameters for querying based on file modification / creation times, but this worked pretty well for me; you just need to narrow the time span so that you pick up the files created by the installer but nothing else).