I have a chroot environment where i am getting folder conflicts when I am running the below command.
/usr/bin/yum --verbose --assumeyes --installroot /home/prateek/project/.ova_work_dir/mnt/dst_root --config=/home/prateek/project/.ova_work_dir/mnt/dst_root/etc/yum.repos.d/project-upgrade.repo --obsoletes groupupdate '*' project
Below is the error
Running transaction test
Transaction check error:
file /usr from install of messagebus_c-1.0.0-0.x86_64 conflicts with file from package filesystem-3.2-20.el7.x86_64
I have below two questions to ask:
1) Why i am getting folder conflict when yum is running transaction test as I have seen file conflicts but not folder conflicts.
2) How would I resolve this folder conflicts.
The messagebus_c RPM specfile needs to be edited to not "own" /usr but instead all the files in it, e.g. /usr/*.
Can you try this ?
/usr/bin/yum --verbose --assumeyes --installroot=/home/prateek/project/.ova_work_dir/mnt/dst_root --config=/home/prateek/project/.ova_work_dir/mnt/dst_root/etc/yum.repos.d/project-upgrade.repo --obsoletes groupupdate '*' project
issue was
missing equal to sign --installroot /home
expected like this --installroot=/home
This can happen when messagebus_c spec file has:
%install
touch %{buildroot}/usr
%files
/usr
I.e. here the /usr is a file. While filesystem provides it as a directory. You cannot have both. A directory cannot be a file. And vice versa.
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.
I have a recipe to compile a printer driver and have a few simple lines to run in do_install.
do_install() {
install -d ${D}${libdir}/cups/filter
install -m 755 ${B}/src/rastertoprinter ${D}${libdir}/cups/filter/
install -d ${D}${sysconfdir}/cups/ppd
install -m 755 ${B}/../rastertoprinter/printer_name.ppd ${D}${sysconfdir}/cups/ppd/
}
To compile the source I have a DEPENDS on cups and also an RDEPENDS on cups as the OS needs cups installed to print of course.
The printer driver is not publicly available so as such I've renamed it to rastertoprinter and changed my path names.
Essentially I need to simply create or ensure the directory /usr/lib/cups/filter exists, and copy the rastertoprinter program there. I also need to create or ensure the directory /etc/cups/ppd exists and copy the .ppd file into that directory.
The first two lines run fine but the 3rd throws the following errors:
file /etc/cups conflicts between attempted installs of printername-r0.corei7_64 and cups-2.2.2-r0.corei7_64
file /etc/cups/ppd conflicts between attempted installs of printername-r0.corei7_64 and cups-2.2.2-r0.corei7_64
I don't understand why both recipes can't create this directory and put stuff in it? Strangely I'm able to do the first /usr/lib/cups/filter directory though fine.
Turns out the issue is that each file to be packaged in Yocto will also generate a %dir for each parent of each file. We don't want to own a directory that is owned by another package, so if you add this to your recipe:
DIRFILES = "1"
It will cause your package to not own parent directories of the files you package.
This will generate an rpm spec file without the %dir entries.
I have downloaded R tree from http://libspatialindex.github.com/
Since on running ./autogen.sh I was getting file/folder not found, therefore I downloaded the file autogen.sh from the github repository given below:
https://raw.github.com/libspatialindex/libspatialindex/9a5a2f4d83c3ec7be4dbf2c8a86341703d837185/autogen.sh
Now when I run ./autogen.sh I am getting "Permission denied"
And if I run sh ./autogen.sh I am getting:
glibtoolize or libtoolize not found. Giving up!
Please suggest what should I do now
EDIT:Also I want to use libspatialindex inside my C++ project. I am using netbeans. I mean I want to use the functions inside libspatialindex inside my netbeans project. How should I use the same. Right now I have run the config and make command in a separate directory. I am not getting as to how to use them inside my project.
Install libtool from your package manager.
To fix the 'Permission Denied' error you need to edit the permissions of your autogen.sh file. Run this command:
chmod +x autogen.sh
I got this error after restoring a library from a Backup to a NTFS directory.
I discovered that another reason this can occur is if the mounted partition has noexec flag on it.
Run mount to see if noexec has been set on the partition.
Update /etc/fstab or add -o exec to the mount command.
Hope, it helps others in the same situation as me.
In the process of building an RPM package, I have to specify the BuildRoot and later will be used in %install which invovles $RPM_BUILD_ROOT. I always think that $RPM_BUILD_ROOT is the fake installation for RPM to perform packaging. Then, at install time using the RPM package, it will install into actual location. For example:
$RPM_BUILD_ROOT/usr/bin
I thought that $RPM_BUILD_ROOT is for the packaging process only, and in some ways RPM can distinguish the $RPM_BUILD_ROOT and the actual install location when the user performs "rpm -ivh package.rpm" will be /usr/bin.
But recently upon reading some documents, it is suggested that $RPM_BUILD_ROOT is the actual location which will be installed, and the $RPM_BUILD_ROOT is specified by user with the setting of environment variable $RPM_BUILD_ROOT in order to let the users install the package in their desire locations. Otherwise, $RPM_BUILD_ROOT will be null and it will install into the default location. In the above case, it is /usr/bin . Thus, $RPM_BUILD_ROOT is not just for packaging or "fake installation" process, but is a way for user to define install location, similar to select folder location in Windows.
I don't know my thinking is correct or not. Can someone please verify? Thanks in advance.
$RPM_BUILD_ROOT (or the equivalent %{buildroot} SPEC file macro) always holds the directory under which RPM will look for any files to package. The RPM scripts (e.g. the script that compresses the manual pages) will also use that value to know where to look for the files that were just installed. Normally, this value will be non-empty and contain a location away from the system directories - usually somewhere under /tmp or /var/tmp.
The author of the SPEC file is expected to make sure that make install (or whatever installer the software in question is using) will place any files under $RPM_BUILD_ROOT, with the same hierarchy that should be used when the software is finally installed. E.g. to have RPM install ls in /bin/ls, the %install SPEC file section should make sure that ls is placed in $RPM_BUILD_ROOT/bin/ls.
The author of the SPEC file is also expected to use the BuildRoot: tag to specify a proper location. Alternatively, the build system could have an rpmrc RPM configuration file with a proper entry. In any case the build root should be set, so that:
Normal users will be able to build the source package.
Should the superuser ever build the source package, the build process will not clobber any system files, unless the superuser installs the resulting binary package. And yes, there may be a good reason to build some packages as root - for example, running the full glibc testsuite requires root privileges for some tests.
That said, RPM can and will build a package with an empty build root variable. In that case both the build install and the final destination locations will coincide. A potential call to e.g. make install will use the default locations, thus clobbering the system files under e.g. /usr/lib if run with sufficient privileges. Additionally, having /usr/bin/* in your %files section will happily pull the whole contents of the build host /usr/bin/ directory into your binary package.
Bottom line:
Never use an empty build root.
Do not build packages as root unless there is absolutely no other way.
the file ~/.rpmmacros defines the paths per user:
%_topdir %(echo $HOME)/rpmbuild
%_tmppath %{_topdir}/tmp
and one can also define them with rpmbuild command line parameters:
rpmbuild --define '_topdir /home/username/rpmbuild'