Question on rpm SPEC - file - openSUSE Packaging

Question on rpm SPEC - file

Dr.-Ing. Dieter Jurzitza

6 Jan 2021 6 Jan '21

15:44

Dear listmembers, I am maintaining an application where I have to run two subsequent compilation processes to care for different screen resolutions. Now, here is my question: I have to apply a patch after the completion of th first compilation and after moving the first binary apart. Unfortunately I cannot do that from the very begin. There is a declaration Patch14: ABCD.patch but I cannot do a %patch14 in the %prep section because this would cause this patch to be effective from the start. Currently I am doing a patch -p0 < ../../SOURCES/ABCD.patch after the first build and after having moved the first binary away but within the %install section of the spec file. However I assume this is not the way it should be ... I mean, this works but I hope there is a more elegant way to get this done within the spec file. Any hints for me? Thank you very much, take care Dieter -- ----------------------------------------------------------- Dr.-Ing. Dieter Jurzitza 76131 Karlsruhe

Show replies by date

Marcus Meissner

6 Jan 6 Jan

16:04

On Wed, Jan 06, 2021 at 04:44:48PM +0100, Dr.-Ing. Dieter Jurzitza wrote:

...

Dear listmembers, I am maintaining an application where I have to run two subsequent compilation processes to care for different screen resolutions.

Now, here is my question: I have to apply a patch after the completion of th first compilation and after moving the first binary apart. Unfortunately I cannot do that from the very begin.

There is a declaration

Patch14: ABCD.patch

but I cannot do a %patch14 in the %prep section because this would cause this patch to be effective from the start.

Currently I am doing a

patch -p0 < ../../SOURCES/ABCD.patch

after the first build and after having moved the first binary away but within the %install section of the spec file. However I assume this is not the way it should be ... I mean, this works but I hope there is a more elegant way to get this done within the spec file.

Any hints for me?

You can reference the patch using %PATCH14 in the spec file. Otherwise it is okay to call patch itself there. patch -p0 < %PATCH14 Ciao, Marcus

Dr.-Ing. Dieter Jurzitza

16:16

Hello Marcus, sorry, no luck: make[1]: Leaving directory '/home/fred/rpmbuild/BUILD/tgif-QPL-4.2.5/po/ru' + /usr/lib/rpm/find-lang.sh /home/fred/rpmbuild/BUILDROOT/tgif-4.2.5- lp152.250.45.x86_64 tgif + cd .. + patch -p0 /var/tmp/rpm-tmp.WvFBLq: line 40: %Patch14: No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.WvFBLq (%install) (the code in the spec - file was patch -p0 < %Patch14 as per your recommendation) seems as if the variable "%Patch14" is not accessible from within the %install section? Thanks again, take care Dieter Am Mittwoch, 6. Januar 2021, 17:04:01 CET schrieb Marcus Meissner:

...

On Wed, Jan 06, 2021 at 04:44:48PM +0100, Dr.-Ing. Dieter Jurzitza wrote:

...
Dear listmembers, I am maintaining an application where I have to run two subsequent compilation processes to care for different screen resolutions.

Now, here is my question: I have to apply a patch after the completion of th first compilation and after moving the first binary apart. Unfortunately I cannot do that from the very begin.

There is a declaration

Patch14: ABCD.patch

but I cannot do a %patch14 in the %prep section because this would cause this patch to be effective from the start.

Currently I am doing a

patch -p0 < ../../SOURCES/ABCD.patch

after the first build and after having moved the first binary away but within the %install section of the spec file. However I assume this is not the way it should be ... I mean, this works but I hope there is a more elegant way to get this done within the spec file.

Any hints for me?

You can reference the patch using %PATCH14 in the spec file. Otherwise it is okay to call patch itself there. patch -p0 < %PATCH14

Ciao, Marcus

-- ----------------------------------------------------------- Dr.-Ing. Dieter Jurzitza 76131 Karlsruhe

Malcolm

16:44

On Wed 06 Jan 2021 05:16:47 PM CST, Dr.-Ing. Dieter Jurzitza wrote:

...

Hello Marcus, sorry, no luck:

make[1]: Leaving directory '/home/fred/rpmbuild/BUILD/tgif-QPL-4.2.5/po/ru' + /usr/lib/rpm/find-lang.sh /home/fred/rpmbuild/BUILDROOT/tgif-4.2.5- lp152.250.45.x86_64 tgif + cd .. + patch -p0 /var/tmp/rpm-tmp.WvFBLq: line 40: %Patch14: No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.WvFBLq (%install)

(the code in the spec - file was patch -p0 < %Patch14 as per your recommendation)

seems as if the variable "%Patch14" is not accessible from within the %install section? <snip>

Hi Sources are available via %{S:nn} , perhaps %{P:14} will work.... -- Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890) Tumbleweed 20210104 | GNOME Shell 3.38.2 | 5.10.4-1-default Intel DQ77MK MB | Xeon E3-1245 V2 X8 @ 3.40 GHz | Intel/Nvidia up 1 day 14:55, 2 users, load average: 4.12, 2.24, 1.65

Dr.-Ing. Dieter Jurzitza

17:28

Hello Malcolm, you made my day :-). Thank you for this hint, this works like a charm (however I'd say that this is not intuitive, but anyway). Thanks guys for helping, have a great start into the new year, take care Dieter Am Mittwoch, 6. Januar 2021, 17:44:48 CET schrieb Malcolm:

...

On Wed 06 Jan 2021 05:16:47 PM CST, Dr.-Ing. Dieter Jurzitza wrote:

...
Hello Marcus, sorry, no luck:

make[1]: Leaving directory '/home/fred/rpmbuild/BUILD/tgif-QPL-4.2.5/po/ru' + /usr/lib/rpm/find-lang.sh /home/fred/rpmbuild/BUILDROOT/tgif-4.2.5- lp152.250.45.x86_64 tgif + cd .. + patch -p0 /var/tmp/rpm-tmp.WvFBLq: line 40: %Patch14: No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.WvFBLq (%install)

(the code in the spec - file was patch -p0 < %Patch14 as per your recommendation)

seems as if the variable "%Patch14" is not accessible from within the %install section?

<snip>

Hi Sources are available via %{S:nn} , perhaps %{P:14} will work....

-- ----------------------------------------------------------- Dr.-Ing. Dieter Jurzitza 76131 Karlsruhe

Stefan Seyfried

19:08

Hi Dieter, On 06.01.21 17:16, Dr.-Ing. Dieter Jurzitza wrote:

...

+ patch -p0 /var/tmp/rpm-tmp.WvFBLq: line 40: %Patch14: No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.WvFBLq (%install)

(the code in the spec - file was patch -p0 < %Patch14 as per your recommendation)

Marcus recommended %PATCH14

...

seems as if the variable "%Patch14" is not accessible from within the %install

I think there is no "%Patch14" variable available anywhere. Case matters ;-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman

Adam Majer

12 Jan 12 Jan

08:34

On 1/6/21 4:44 PM, Dr.-Ing. Dieter Jurzitza wrote:

...

Dear listmembers, I am maintaining an application where I have to run two subsequent compilation processes to care for different screen resolutions.

Now, here is my question: I have to apply a patch after the completion of th first compilation and after moving the first binary apart. Unfortunately I cannot do that from the very begin.

Make 3 different binary packages. One for each resolution and then the common one (the current binary package) that depends on the 2 special cases. The user just installs the main one and pulls in the 2 special cases. Maybe you can use _multibuild for various @BUILD_FLAVOR@ You could also name the actual package so we don't have to guess. - Adam

Dr.-Ing. Dieter Jurzitza

18:53

Hello Adam, thank you for your suggestion. However, I solved the issue differently: - I am building "tgif" standard resolution first and save the binary to tgif.Stdres - I am building "tgif" high resolution second and save the binary to tgif.Highres both tgif.Stdres and tgif.Highres are part of the original package. As a default a symlink tgif -> tgif.Stdres is generated. During installation of the package the installation scriptlett determins the resolution of the display. Depending on this information both the link /usr/ bin/tgif and the geometry - settings in /usr/share/X11/app-defaults/Tgif are adjusted accordingly. If the user decides to switch to a different display (having a different resolution) at any time he ca run a script called tgif-reconf. During this call the settings are adjusted - if the resolution reaches beyond 3000 points horizontally it switches to the high-res version. I consider this quite user-friendly, I hope my assumption is true, though :-) Take care Dieter Am Dienstag, 12. Januar 2021, 09:34:16 CET schrieb Adam Majer:

...

On 1/6/21 4:44 PM, Dr.-Ing. Dieter Jurzitza wrote:

...
Dear listmembers, I am maintaining an application where I have to run two subsequent compilation processes to care for different screen resolutions.

Now, here is my question: I have to apply a patch after the completion of th first compilation and after moving the first binary apart. Unfortunately I cannot do that from the very begin.

Make 3 different binary packages. One for each resolution and then the common one (the current binary package) that depends on the 2 special cases. The user just installs the main one and pulls in the 2 special cases.

Maybe you can use _multibuild for various @BUILD_FLAVOR@

You could also name the actual package so we don't have to guess.

- Adam

-- ----------------------------------------------------------- Dr.-Ing. Dieter Jurzitza 76131 Karlsruhe

Stefan Seyfried

13 Jan 13 Jan

19:25

On 12.01.21 19:53, Dr.-Ing. Dieter Jurzitza wrote:

...

Hello Adam, thank you for your suggestion. However, I solved the issue differently:

- I am building "tgif" standard resolution first and save the binary to tgif.Stdres - I am building "tgif" high resolution second and save the binary to tgif.Highres

both tgif.Stdres and tgif.Highres are part of the original package. As a default a symlink tgif -> tgif.Stdres is generated.

During installation of the package the installation scriptlett determins the resolution of the display. Depending on this information both the link /usr/ bin/tgif and the geometry - settings in /usr/share/X11/app-defaults/Tgif are adjusted accordingly.

This (crazy ;-) hack only works if the user is logged in on the display that's used later to use the program. It does not work if you change to VT 1, log in as root and do "zypper in tgif" or "zypper dup", which is what I do often to avoid problems with crashing X servers during package updates leaving the update in a half-installed state. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman

Dr.-Ing. Dieter Jurzitza

19:41

Hello Stephan, if no X-server is running you will get standard resolution and standard configuration. If the X-server is "dead" the very same will happen. But this is a theoretical approach anyway as the program is not usable in this case. And no "ordinary" user will switch to the plain console mode IMHO any more. I would speculate that the "ordinary" user might even not be aware of keys like Strg-Alt-Fx ... If you want to know the gory details -> take a look into the spec file. Anyone having an idea on how to better support the user - tell me :-) By the way: if you run "tgif-reconf" afterwards (that said, being logged into a X-session) the appropriate settings matching your screen will get configured. At least such best-guess settings that provide an IMHO usable configuration to an unexperienced user. Anyone knowledgeable about direct editing of /usr/share/X11/app-defaults/Tgif and/or .Xdefaults-<HOSTNAME> can do so any time. But this will be a minority, I bet. Any suggestion on how to improve the behavior is very welcome. IMHO this is the best possible approach to support a user with not too much in-depth knowledge. Take care Dieter Am Mittwoch, 13. Januar 2021, 20:25:06 CET schrieb Stefan Seyfried:

...

On 12.01.21 19:53, Dr.-Ing. Dieter Jurzitza wrote:

...
Hello Adam, thank you for your suggestion. However, I solved the issue differently:

- I am building "tgif" standard resolution first and save the binary to tgif.Stdres - I am building "tgif" high resolution second and save the binary to tgif.Highres

both tgif.Stdres and tgif.Highres are part of the original package. As a default a symlink tgif -> tgif.Stdres is generated.

During installation of the package the installation scriptlett determins the resolution of the display. Depending on this information both the link /usr/ bin/tgif and the geometry - settings in /usr/share/X11/app-defaults/Tgif are adjusted accordingly.

This (crazy ;-) hack only works if the user is logged in on the display that's used later to use the program.

It does not work if you change to VT 1, log in as root and do "zypper in tgif" or "zypper dup", which is what I do often to avoid problems with crashing X servers during package updates leaving the update in a half-installed state.

-- ----------------------------------------------------------- Dr.-Ing. Dieter Jurzitza 76131 Karlsruhe

Andrew Daugherity

21:37

...

On Jan 13, 2021, at 1:41 PM, Dr.-Ing. Dieter Jurzitza wrote:

Anyone having an idea on how to better support the user - tell me :-)

Hmm, maybe the /etc/alternatives system would be useful here? There’s even a YaST module for managing it... -Andrew

Dr.-Ing. Dieter Jurzitza

14 Jan 14 Jan

19:03

Hello Andrew, thanks, this indeed would have worked - with one restriction: determining a "best guess" of the geometry settings will require additional efforts (like the way I did) in order to work properly. So, this would be a "yes and no" situation: yes, you can manage two (or more, but this does not apply here ...) different binaries and two different app- defaults - files. And no, it will not change the underlying problem that you need information regarding the screen size to determine appropriate parameters for the geometry setting in /usr/share/X11/app-defaults/Tgif .... and this is what IMHO had been questioned by Stefan .... Take care Dieter Am Mittwoch, 13. Januar 2021, 22:37:09 CET schrieb Andrew Daugherity:

...

...
On Jan 13, 2021, at 1:41 PM, Dr.-Ing. Dieter Jurzitza wrote:

...

...
Anyone having an idea on how to better support the user - tell me :-)

Hmm, maybe the /etc/alternatives system would be useful here? There’s even a YaST module for managing it...

...

-Andrew

-- ----------------------------------------------------------- Dr.-Ing. Dieter Jurzitza 76131 Karlsruhe

1205

Age (days ago)

1213

Last active (days ago)

List overview

Download

11 comments

6 participants

participants (6)

Adam Majer
Andrew Daugherity
Dr.-Ing. Dieter Jurzitza
Malcolm
Marcus Meissner
Stefan Seyfried

Question on rpm SPEC - file

tags

participants (6)