1

A little background - Since Redhat stopped updating gcc versions for RHEL6, we had to implement our own gcc5 deployment.

We can't upgrade to RHEL7 at this time, nor will it solve this problem as Redhat hadn't deployed gcc5 for rhel7 yet.

Our current issue is with /usr/src/kernels/$(uname -r)/include/linux/compiler-gcc5.h

That path and the compiler-gcc*.h files are owned by kernel-devel, and a gcc5 one exists only for fedora (only for distros where gcc5 has been introduced officialy).

I can easily create an rpm that will own the file (the reason is mainly so we will receive a conflict if RH ever deploys kerenl-devel with that file, so we can stop deploying our own) for the current kernel, but I'd like to use %triggerin to copy the file to any new kernel-devel installed on the system.

using uname -r wouldn't work for 2 reasons:

  1. it's evaluated at rpmbuild time, not install time.
  2. it evaluates the current running kernel, not the future one just installed.

I can overcome 1 by using a %post script, I think, but can't figure out how to overcome 2, nor how to own the file by my rpm in it's final location (can I %ghost a path I don't know in advance, or use something like dkms?)

Is there a way to know the exact version of the rpm that triggers the %triggerin and incorporate it into the path?

Is there an alternate solution?

Dani_l
  • 613
  • 5
  • 14
  • Not sure what you mean with `uname -r` regarding 1. but anything inside the trigger will evaluate during runtime of the trigger, not during rpmbuild time. And yes you can %ghost any path, but you would have to define it at build time before %files section is written, and wildcards won't work there for files that are not present yet, as I don't think it will actually glob paths on the target system. What you could do is to copy your file to `/usr/src/kernels/*/include/linux/compiler-gcc5.h` in the trigger, and display some dialog, as you have to define the Conflicts during build time ... – doktor5000 Sep 24 '16 at 15:05
  • In addition, even if you would %ghost the file, if two packages contain the same file in the same path, the file conflict will silently be ignored if the md5sum of the file is exactly the same (depending on your exact rpm version) so ownly owning the file in your package would not help in all cases. – doktor5000 Sep 24 '16 at 15:08
  • @doktor5000 re: 1 I meant that I assumed a path like ..../kernels/$(uname -r)/... would evaluate during rpm build time, not during the trigger runtime. Regarding the 2nd issue - if the hash is the same, than I don't really care, I guess. Thanks for your help. – Dani_l Sep 26 '16 at 05:54
  • As you mentioned triggers, there would indeed be another option, which to the best of my knowledge is only supported by newer rpm versions (>= 4.13 as in e.g. RHEL7) - file triggers. You can define a path, and then rpm will give you a list of files under that path added/changed during the rpm transaction, and you can run any commands on them. That would give you the option to run a small scriptlet which basically checks or replaces the header file. See http://www.rpm.org/wiki/FileTriggers or https://wiki.mageia.org/en/RPM_filetriggers#Usage - just say if you need more details ... – doktor5000 Sep 26 '16 at 14:33
  • If you need to upgrade your GCC, I really worry that you're accepting a lot of risk and continual follow-on work (monitoring for exploits, devising fixes, testing fixes, packaging fixes, testing packages, deploying fix packages, installing fix packages under a change control) that you may not realize on the way in. And that doesn't address the requirements your customers now need to fulfill ! If you're installing a new gcc because of developer demand, it may be easier to explain to the developers that concept cars aren't driven directly from the car show, and that the platform is EL6. – user2066657 Aug 24 '17 at 02:42
  • @user2066657 The new GCC is deployed outside system PATH (i.e, it deploys to /opt/... same as software collections). It deploys in a disjoint site (not connected to the internet) so security issues are of somewhat lesser concern, but a maintenance cycle does exist. When possible I use software collections, but latest gcc version are not always present. Thanks for your comment. – Dani_l Aug 24 '17 at 06:41

0 Answers0