Mailinglist Archive: opensuse-buildservice (233 mails)

< Previous Next >
Re: [opensuse-buildservice] Re: %make_install in prjconfig
On 11/8/2013 11:51 AM, Guido Berhoerster wrote:
* Brian K. White <brian@xxxxxxxxx> [2013-11-08 16:30]:
On 11/7/2013 10:27 PM, Jan Engelhardt wrote:

On Thursday 2013-11-07 23:56, Brian K. White wrote:

The current .spec from factory uses %{make_install}
OS versions before 11.2 do not have that macro.

I got it working by making this change to the .spec from the current version
1.8 in factory:

- %{?make_install}

+ %{?make_install} %{!?make_install:%%{__make} install DESTDIR=%{buildroot}}

You can see how horrible that looks. (And it won't be any
better if you stash it in a prjconf.) Just write

make install DESTDIR="%buildroot"

like suggested in all openSUSE (en) wiki entries that mention installation.

I would love it if the devel package actually did that.
I'll SR that and maybe request a maintainer role.

Just to let you know, I have rejected Jan's sr's with such
changes to my packages in the past and I will reject such a sr to
tmux for the reasons Tomáš mentioned. This can be worked around
through projconf and ultimately needs be fixed in SLE, not using
a macro means that future policy/autotools changes will be much
harder to implement in an automated fashion.


I thought as much.

This is why I didn't both SR before.

Thanks for caring. That's why I love working on and with openSUSE so much the last few years. For the record, I think this attitude sucks.


So, rest of list, given this jerks position, how might one work around it?

To summarize the point I raised in my other post:

Be it a change in OBS itself or a change in a prjconfig, providing a macro (or anything else for that matter) in OBS for a target that doesn't natively have it, produces a .rpm that will install, yet produce a src.rpm that will NOT build.

Off hand I can think of two possible ways to work around this:

1) Make a new package that provides the missing macros? You can then just install the package on the target like any other buildrequires, thus making the src.rpm valid again.

2) Something even fancier in prjconfig? Can you get prjconfig to actually write out a different .spec into the src.rpm than the one that was used to create it?

So, the .spec says %{make_install}, and when OBS writes out the src.rpm, it edits .spec on the fly and writes some pre-defined substitution in place of %{make_install} in the .spec in the src.rpm. The .spec in the OBS project remains unchanged. It should NOT simply expand %{make_install}, because that will result in the src.rpm has a .spec with hard coded path and other values. Even if it would always build the same, which I'm not actually sure of, it doesn't reflect what the .spec author wrote and it's a less useful .spec in it's own right to take as a starting point for local manual editing or learning from. So it has to be a fixed closest approximation that somebody works out ahead of time that probably uses %makinstall for some targets and %__make and %buildroot for others, etc. Whatever is best for each target.

#2 would probably be the best. This way everyone's happy. OBS can stay all nice and tidy, taking advantage of the most current system, and yet the generated src.rpm still builds on a native system, and no need to find and install a weird new package that isn't going to be found in any of the normal repos.

--
bkw
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-buildservice+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups
References