I have some source files and one bash script to run during installation in Ubuntu machines.
What is an easy guide to Debian packaging and create packages for own use?
My practice includes:
I made a sample which copies the files in to /usr/bin/ folder using pbuilder environment, but got struck with running a process.sh file which contains:
set -x
cpath=`pwd`
cd /usr/local/
mkdir libexec
cd
cd $cpath
cp askpin /usr/local/libexec/
cp badpin /usr/local/libexec/
cp msg /usr/local/libexec/
ldconfig
Any help is appreciated.
Traditionally these scripts go into the debian/DEBIAN directory along with the control file and are called preinst, postinst, prerm and postrm.
They are run when it is appropriate by the installation/removal process.
Include a shebang at the top of these files.
See: https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html
Edit:
Just chased down pbuilder and realised that the above answer probably means nothing to you.
I didn't know pbuilder existed, if I had maybe I would have used it, instead of scratching my debian builds into the bare metal, where the above answer makes sense.
Related
As far as I know, Flutter for linux app only targets snap packaging format.
Is it possible to generate .rpm and .deb (cross-linux platform) software packages from the flutter build?
Kindly post any help on how to package a flutter-linux app as RPM package
Building RPMs and DEBs is doable, but a pretty involved process. I will try to outline the basic process for RPM's as best as I can. The process of making a DEB is mostly the same with a few differences. I will stick to RPM's for now.
The main thing which is a pain is that to build packages you need specific tools which are only available on the distros. So if you want to do this cross platform (generate a RPM on a ubuntu machine for example) we need to use Docker.
Create a Dockerfile which in which we will install the rpm-build package which contains all tools to build RPMs.
FROM centos:7
RUN yum install -y -q rpm-build
Build this dockerfile and remember the docker image, we will need it later.
Execute the following command mkdir -p build/{BUILD,RPMS,SOURCES,SPECS,SRPMS}. This will create the directory structure required for rpmbuild
Create a .spec file, this file is a config file for the rpmbuild command and place it in the build/SPECS directory. The contents of this file are very specific to the what the package has to do. RPMs are very flexible and can do lots of stuff ranging from just copying files to running complex bash scripts on the target machine to perform compilation on the target machine and perform complex installations. Here are some guides which I found useful: package guide, fedora guide, and redhat guide.
Download the files you want to package, often they are distributed as tarballs and place it in the build/SOURCES directory.
Now we can execute the following command docker run --rm -v $(pwd)/build:/rpmbuild {name of image} /bin/bash -c "cd /rpmbuild && rpmbuild --define '_topdir /rpmbuild' -ba SPECS/flutter.spec"
I will break the command down.
docker run --rm -v $(pwd)/build:/rpmbuild {name of image} - we start a container from the image we created earlier, and mount the build dir in which our .spec and .tar.gz are located so the container can see them. --rm cleans up the container after we are done since we don't need it after the first command.
/bin/bash -c - this is a trick since we need to execute 2 command inside the docker container, if we don't do this our shell will thing the && is meant after the docker command and not passed to the container.
"cd /rpmbuild && rpmbuild --define '_topdir /rpmbuild' -ba SPECS/flutter.spec" - move to the mounted build directory and build the RPM package. the -ba option tells rpmbuild to build both the binary and source packages in case you want the source package as well.
If all went well your should now have an .rpm file in the build/RPMS and a source package in the build/SRPMS directory.
For DEB the process is almost the same, except you need a debian or ubuntu docker image, you use the dpkg-deb command to build and you need a control file instead of a .spec file(same purpose different format)
I will also go over some of the key parts of building rpm packages for flutter applications in case the previous answer was ambiguous.
I have already written an article going into details but here I will only highlight the key parts. You can find the article here
Also for simplicity of explanation, I will be using cool-app as an example throughout this post.
1- Run flutter build linux to get the Linux build inside the build folder in your project root directory.
2- Copy your bundle folder someplace else and there, rename it according to app-name-version semantic. e.g. cool-app-1.0.0
3- Create a .desktop file. e.g. cool-app.desktop will look like the following :
[Desktop Entry]
Name=My Cool App
Comment=A cool app that does everything
Exec=/usr/bin/cool-app/cool-app
Icon=/usr/bin/cool-app/data/flutter_assets/assets/icon.svg
Terminal=false
Type=Application
Categories=Utility;
change the properties accordingly and place the .desktop file inside cool-app-1.0.0 directory
4- run mkdir -p rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS} in your home directory.
5- copy the cool-app-1.0.0 directory to ~/rpmbuild/SOURCES.
Due to a problem that as the time of writing this still persists, the rpath for lib*_plugin.so files point to user's build tree path which results in rpmbuild failure.
6- Run patchelf --print-rpath * inside cool-app-1.0.0/lib and check the output. If the output contains a path from your home directory, run patchelf --set-rpath '$ORIGIN' * to fix the rpaths, then check again. now all paths must be $ORIGIN. (This was the way I was able to fix it, not sure if it's the best solution)
You can check this github issue for further information.
7- cd into ~/rpmbuild/SOURCES and run tar --create --file cool-app-1.0.0.tar.gz cool-app-1.0.0 to create a tar.gz file.
8- Create a file named cool-app.spec inside ~/rpmbuild/SPECS directory.
Sample cool-app.spec file :
Name: cool-app
Version: 1.0.0
Release: 1%{?dist}
Summary: Very cool app
BuildArch: x86_64
URL: https://github.com/CoolDev/cool-app
License: GPLv3
Source0: %{name}-%{version}.tar.gz
Requires: bash
%description
A very cool app that does everything
%prep
%setup -q
%install
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT/%{_bindir}/%{name}
cp %{name} $RPM_BUILD_ROOT/%{_bindir}/%{name}
cp -R lib $RPM_BUILD_ROOT/%{_bindir}/%{name}
cp -R data $RPM_BUILD_ROOT/%{_bindir}/%{name}
desktop-file-install %{name}.desktop
%clean
rm -rf $RPM_BUILD_ROOT
%files
%{_bindir}/%{name}
/usr/share/applications/
You could use the same template and only change Name,Version,Summery,Release,BuildArch,URL,License,%description and you will most likely be fine.
I went over the spec file in more detail in my article mentioned in the beginning of this post.
9- run rpmbuild --bb cool-app.spec to get your rpm file inside ~/rpmbuild/RPMS directory.
I have this internal software installer that has a size > 4.9GBs,
it installs a bunch of rpms/libraries and set some configs at the end.
I need to create a RPM using rpmbuild(Im new to this rpm creation) in order to install the RPM and also proceed to install/execute this installer(its a bash file).
My rpm spec is currently doing this at (you can check the code below):
%install
Copy 2 zips files into a specific folder.
This are 2 zip files from the actual software folder, I just splitted its
content in 2 parts and zip them to avoid the max size limitations(4gbs if Im
not wrong).
%post
Unzip those files into a specific folder.
run the bash script installer that was inside those zip files (it will run silently because a -s flag that it has).
Complete the bash and rpm installation successfully.
I had alredy built the rpm, so when I try to:
yum install .rpm,
it does the zip part just fine but it stays forever doing nothing at the bash installation part, maybe because this rpm lock thing, but I'm not sure.
By the way, Im not sure at all if this is a good approach for this at the end, I mean combined this rpm and installation stuff
So because the install.sh part is giving me this issues I tried this different changes:
sudo /root/sotfware/install.sh -silent /root/software/silent_configfile.conf
/root/sotfware/install.sh -silent /root/software/silent_configfile.conf
./root/sotfware/install.sh -silent /root/software/silent_configfile.conf
What do you guys thisnk I'm doing wrong?,
Whats the best way to do this? or
Whats you recommendation for this?
This is the spec file:
Name: software-19
Version: 1.0
Release: 1
Summary: software 2019
License: N/A
URL: https://
AutoReqProv: no
AutoReq: no
%description
Some description
%install
mkdir -p %{buildroot}/root/software2019
cp /root/software/software-1.zip %{buildroot}/root/software2019/software-1.zip
cp /root/software/software-2.zip %{buildroot}/root/software2019/software-2.zip
%post
unzip /root/software/software-1.zip -d /root/software2019/
unzip /root/software/software-2.zip -d /root/software2019/rpm/
sudo /root/software/install.sh -s /root/software2019/silent_configfile.conf
rm -rf /root/software/
%clean
rm -rf %{buildroot}
%files
/root/software/*
%changelog
* Tue Jan 20 2019 1.0
- Initial release
Hopefully Im been clear, thanks in advance!
You have multiple issues here
You are building RPMs as root, which is dangerous and can wipe your machine if you don't write things correctly. Since you're just getting started, this is much more likely.
The source files shouldn't have absolute paths.
You shouldn't use sudo because RPM installation is always run as root.
silent_configfile.conf wasn't included in the RPM, so the target machine might not have it.
The %post deletes the files that you told RPM you would install, likely causing errors.
This would also break rpm -V verification.
You are misusing the RPM system by doing a third-party install in your %post.
This breaks things like rpm -q --whatprovides /root/software19/myfile.
This breaks rpm -V because it cannot verify the files you installed.
This breaks any concept of uninstall / upgrade because you don't provide %preun and related files to "do the right thing."
To do things right and not cause your admins headaches for years to come, you need to have those installers run during RPM creation (again, not as root!) with a target of %{buildroot} and then distributing the resulting file structure as an RPM. If this is not something that can be done, then RPM is probably not going to work for you and you need to look at other distribution options, like custom scripts.
Created a simple debian/ubuntu package with some library files (*.so).
Works fine except, it installs them as default in the root path "/".
Since I've recreated my Makefile to output to $DESTDIR/ instead of "the usual" directory that I provide in the Makefile, when compiling from source, how do I now set the path of where the files should be installed now? I know there are several choices when using dh_make to create the package, "s" being the default one. Still, can't seem to find anything on where to tell dpkg to put the installed files.
Secondly, a Deb Library package containing only ".so" files should still be a "Single binary" since I gather that using the Library is for development purposes? Since this is a library, I just wanna make sure that's not the cause of the files being installed in the wrong location. What I mean is .so files and header files installation?
What I've used:
dh_make -e my#email.com -f ../myfile-1.0.tar.gz
dpkg-buildpackage -rfakeroot
and some configurations set i debian/control, $DESTDIR in Makefile.
Seems that it was fairly simple, yet very confusing. This works, not sure if there is a better solution.
In my makefile I have a few variables
InstallTo = /usr/lib
install:
mkdir -p $(DESTDIR)$(InstallTo)
cp $FILE_TO_COPY $(DESTDIR)$(InstallTo)
This way it will create the directory tree inside the *.deb file. I had some trouble using /usr/local/lib instead of /usr/lib/ and rmdir complained when trying to delete it and it had no files (just directories). Not sure why, but changed it to /usr/lib instead.
Since someone voted this up, I'm guessing someone were also looking for the answer and this is my solution. Perhaps someone can provide a better one if there is one.
Just a note, $DESTDIR variable is the variable that dh_make suggest the user to use in our Makefile. It's the path to where dpkg will build the program and where it will install it so it can be included in the .deb file.
Archlinux.
I downloaded mtools, which includes mcopy, which is what I'm after. The instructions in the INSTALL file say do this:
# ./configure
# make
These worked fine, now I have a bunch of .o files and of course executables.
What do I need to do, so I can just type
# mcopy
and have it run? Since I don't have it "installed" right now, doing that just says
-bash: mcopy: command not found
The usual linux build sequence is
./configure
make
make check
sudo make install
make check attempts to validate if the build took place correctly; not all Makefiles have it but many do. Note you will need sudo make install to do the install in the usual system directories if you are not root.
You can determine which of these options is available for your particular Makefile by
cat Makefile
and reading the labels on the left of the file.
You could create a symbolic link to the application in your /usr/bin folder like
ln -s /fullpath/to/app /usr/bin/aliasnameforapp
Then you can simple call aliasnameforapp from anywhere.
I have a debian package that I built that contains a tar ball of the files, a control file, and a postinst file. Its built using dpkg-deb and it installs properly using dpkg.
The modification I would like to make is to have the installation directory of the files be determined at runtime based on an environment variable that will be set when dpkg -i is run on the deb file. I echo out the environment variable in the postinst script and I can see that its set properly.
My questions:
1) Is it possible to dynamically determine the installation directory at runtime?
2) If its possible how would I go about this? I have read about the rules file and the mypackage.install files but I don't know if either of these would allow me to accomplish this.
I could hack it by copying the files to the target location in the posinst script but I would prefer to do it the right way if possible.
Thanks in advance!
So this is what I found out about this problem over the past couple of weeks.
With prepackaged binaries you can't build a debian package with a destination directory dynamicall determined at runtime. I believe that this might be possible if installing a package that is built from source where you can set the install directory using configure. But in this case since these are embedded Ubuntu machines they don't have make so I didn't pursue such an option. I did work out a non traditional method (hack) for installing that did work. Since debian packages simply contain a tar ball relative to / simply build your package relative to a directory under /tmp. In the postinst script you can then determine where to copy the files from the archive into a permanent location.
I expected that after rebooting and the automatic deletion of the subdirectory under /tmp that dpkg might not know that the file package existed. This wasn't a problem. When I ran 'dpkg -l myapp' it showed as still installed. Updating the package using dpkg/apt-get also worked without a hitch.
What I did find is that if you attempted to remove the package using 'dpkg -r myapp' that dpkg would try and remove /tmp which wasn't good. However /tmp isn't easily removed so it never succeeded. Plus in our situation we never remove packages but instead simply upgrade them.
I eventually had to abandon the universal package due to code differences in the sources resulting in having to recompile per platform but I would have left it this way and it did work.
I tried using --instdir to change the install directory of the package and it does relocate the files but dpkg fails since the dpkg file can't be found relative to the new instdir. Using --instdir is sort of like a chroot. I also tried --admindir and --root in various combinations to see if I could use the dpkg system relative to / but install relocate the files but they didn't work. I guess rpm has a relocate option that works but not Ubuntu.
You can also write a script that runs dpkg-deb with a different environment for 6 times, generating 6 different packages. When you make a modification, you simply have to run your script, and all 6 packages gets generated and you can install them on your machines avoiding postinst hacking!
Why not install to a standard location, and simply use a postinst script to create symbolic links to the desired location? This is much cleaner, and shouldn't break anything in dpk -I.