It is common practice to customize a Yocto made package with an Bit Bake append file _%.bbappend. The problem I am having is even though the package contents have been modified due to the append file, the package keeps the same version number. This is troublesome because dnf install will not install the RPM because it does not think it is an upgrade and a dnf remove before would trigger dependent packages to also be removed. There are ways around this modifying DNF configs, but I get nervous automating those changes in utilities due to the chance of really nasty error states.
Assuming the original package is installed, is there any way to modify the Bit Bake append file so that dnf will install the result like an updated package?
The solution to this is to use the PR service:
https://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#working-with-a-pr-service
I believe you want to set (and increment as you update) the PR variable as follows:
PR = "r1"
See: https://www.yoctoproject.org/docs/2.5/mega-manual/mega-manual.html#var-PR
Related
This question is somewhat similar to the one here, but I cannot make it work.
So suppose that I have a set of packages (say 2) to install and I want to use pipenv. If I do pipenv install on the directory with a suitable Pipfile the installation fails because there is some metadata issue when installing one of the libraries (say libX) contained in install_requirements of one of the packages. It seems that the problem can be fixed by downgrading the version of setuptools to <=58.0.0.
OK. Now, if I first install that version of setuptools<=58.0.0 in the venv and then install my packages, everything works fine. The issue is that the Pipenvfile does not respect the order when installing, so something like
[packages]
setuptools = "<=58.0.0"
pckg1 = {<github path 1>}
pckg2 = {<github path 2>}
is not ensured to work. Also, by default the seed packages added to the venv include setuptools==65.6.3.
So the idea is to be able to restrict the version of setuptools that is used to check the metadata of the libraries in libX, to mimic the above scenario in which setuptools was installed first. Is there a way to do that?
I have tried placing setuptools<=58.0.0 at the top of the requirements.txt that defines the install_requirements of the problematic package, but it does not work.
If have also tried to fix or restrict the version of libX contained in that requirements.txt file but, surprisingly, pipenvdoes not seem to care: a verbose install shows that it keeps downgrading libX well below the restriction - "using cached libX-vX.X.X"- until it uses a version for which the metadata generation fails (why on earth does it do that, even if I call it with pipenv --clear install?).
I am a bit lost about what could be the best solution here. Any help would be very appreciated.
If I build my own RPMs, is there a way, to tell that before upgrade to the latest version, upgrade to a specific other version first?
So for example I often made a mistake in my postun actions, that I delete a link. So when I want to update to an newer package that fixes my postun action, the usually RPM behavior is that my new packages will be installed, then the old package will be uninstalled and trigger my mistake in the postun action. So I would need to run a reinstall then or to update again to an even later version, that on the next update, my postun action is correct.
So I would imaging something like
UpdateRequires: MyPackage >= 1.1
There is no way to force an update chain like that. You could have the user reinstall the new package. Another option is to fix the symlinks in your %verify stanza and tell the user to run rpm -V on your RPMs.
It is possible to run a step after old packages %postun with %posttrans in new package
I can't seem to find anything useful in the man pages etc for this, but it seems like it should be straightforward..?
Our servers are running CentOS 6.8 but also have the Atomic repository for some package versions. The most recent version of one of the packages that Atomic provides seems to be broken, so we've had to do a yum downgrade of that package.
Problem now is that we're running Plesk, which performs automatic Yum updates on a schedule, and the next time this happens, the broken package will just drag back in again!
All I want to do is tell Yum to ignore this specific package version so that it updates the next time there's a newer version, but skips the current.
I found that I can add exclude= lines to yum.conf but I can't seem to find how to define a specific version number in this exclude. It looks like I can only exclude entire package names?
I'm more familiar with Gentoo where we can tell Portage to mask specific versions when problems like this occur. Is this not an option in CentOS?
Much appreciated.
I have created a relocatable RPM using the instructions in this website:
http://www.cyberciti.biz/faq/rpm-relocatable-packages/
This means that I can install the package into its default location, /opt/app, using
rpm -ivh mypackage.rpm
However, if I decide that I weant the package to be installed into /usr/local/bin instead, I can install it using:
rpm -ivh --prefix=/usr/local/bin mypackage.rpm
All of this works perfectly. However, I need to install the package via Yum. How do I pass the --prefix argument to Yum?
I don't believe this is possible and a quick online search seems to concur. Including this mailing list thread from 2007. The point that Seth Vidal makes in his reply is, I think, the main one. Relocations cause problems for file-based dependency tracking which, at least at the time, nothing bothered to handle.
That being said I think the utility of relocatable RPMs is likely not very high as building one that functions correctly is difficult as not being able to depend on file locations makes many (normally trivial) programmatic operations quite difficult.
I have spent all day trying various things and made no progress whatsoever.
I am compiling an rpm package for my application (MyApp.rpm), for RHEL6 64-bit, which requires a third party, 32-bit driver package called aksusbd.rpm. Now, aksusbd.rpm in turn requires compatibility mode, provided on RHEL6 by glibc.i686.rpm.
So somewhere in my spec file for MyApp.rpm I have:
MyApp.spec
Requires: glibc(x86-32)
Requires: aksusbd >= 1.14
What it does during installation (yum install MyApp) is, installs aksusbd first, which fails with no 32-bit compatibility installed. Then just to tease me, immediately after installs glibc. So when its all over I can type
yum install aksusbd
and it works this time because glibc is now installed.
How on earth do I teach it to do better than this!
(growl)
You can follow Aaron's suggestion and tweak the third party RPM you have with rpmrebuild. It allows you to modify the requires spec of the RPM package:
rpmrebuild --package -n --edit-requires <your third party rpm package>
It's a hack but just for the requires tags in the RPM I would not be concerned.
First off I'd suggest putting the requires on the same line. Just separate them with a comma, they should then go in the order you've specified. If it doesn't and you're on RPM version 4.3 or below, you can use the PreReq tag as specified in the rpm.org docs about half way down the page.
If neither of those solutions works, or you are on a version of RPM greater than or equal to 4.4 I would imagine something else is going on that is causing a problem. I'd start by creating a new spec for some 'fake' project that specifically targets the issue of glibc not being installed before aksusbd. If that works we know it's something with your MyApp.spec, if it doesn't work then I'd suggest reviewing the naming convention of glibc, perhaps there is some kind of issue with how it's interpreting your (x86-32).
Sounds like the aksusbd RPM is what needs to be fixed - they need a Requires or Requires(pre) set. File a bug with the driver vendor.
I had exactly the same problem (and same in YUM groups). If Forrest suggestion to put requires in same line works for you, please let us know.
Otherwise, you can try to add an RPM that only requires aksusbd and add it to requires list. If YUM installs dependencies in an Alpha-beta order, name it something between aksusbd and glibc and it might work.