Set perms for file in rpm

Applications
#1

Hi, I’m having two packaging problems that I’m stuck at:

  1. although I haven’t explicitly set anything and the file is in the qml/ context, it’s being set executable. That’s not allowed, It’s a python file qml/py/myfile.py. how do I stop that?
  2. I need to do some excludes for local libs: Do not check .so …
    somethinng like # %global __provides_exclude_from ^(%{_libdir}/%{name}/.\.so.|%{_datadir}/myapp/.*)$
    But what file do I use?

this is a INSTALL+= python project.

I can actually deploy without problems but I won’t get this into the jolla store :slight_smile:

#2

You can set permissions in the .spec or the .yaml file.

Either by switching %defattr:

Yaml:

Files:
  - '%defattr(644,root,root,-)'  # <-- this will apply to all following files that have no attr of their own
  - '%{_datadir}/%{name}/qml/py/*'

… or by setting the permissions for just one file using %attr:

Files:
  - '%attr(644,root,root) %{_datadir}/%{name}/qml/py/myfile.py'

These are just RPM macros, so if you only have a .spec they look the same (without the ticks and dashes).

#3

Thanks! Any Idea why it’s being set 755 when all the other qml files are set 644?

#4

Probably done by the make install phase, and the rpm packaging just copies the files over keeping permissions.
Per default it only sets dir permissions and leaves files as they are in buildroot.

#5

Ok, so I found the point where provides_exclude is referenced vis. the spec file. but how in the yaml. jeez.

is supposed to go between the macro brackets but in the yaml you’re supposed to provied. ?

  • ‘%define __provides_exclude_from ^%{_datadir}/.*$’
#6

Got it:
https://wiki.merproject.org/wiki/Spectacle

States that modifying the spec file in the macro section will survive updates. Which begs the question, WT? is the purpose of the yaml file?

#7

Great. It. Is. Not. True. The changes are wiped out. so you can’t use the SDK. great. well.

So, Before I go too much further I need to consider getting rid of Silica? Or skipping deploying to the jolla store? Jeez.

I’m at 8 hours of no progress on features and bugs and all jumping through hoops with a broken IDE.

#8

Careful, what they mean my macros is these sections:

# >> build post
# << build post

Anything you put in between will not be overwritten when you update the spec from the yaml. Anything outside will.

WT? is the purpose of the yaml file?

That’s a dangerous question I will not put my opinion towards ;D But I understand it’s basically a MeeGo/Mer legacy.

Anyway you don’t strictly need to use yaml files, you can build using just a spec file just fine.

1 Like
#9

Looks like kill the yaml is the answer :slight_smile:

In any case the howtos don’t get me there:

# >> macros
%define __requires_exclude ^_imagingtk.cpython-38-arm-linux-gnueabihf|_imagingmorph.cpython-37-arm-linux-gnueabihf|_imagingmath.cpython-38-arm-linux-gnueabihf|_imagingft.cpython-38-arm-linux-gnueabihf|_imagingft.cpython-38-arm-linux-gnueabihf|_imagingft.cpython-38-arm-linux-gnueabihf.*$
# << macros

doesn’t get me there. so there is probably some regexp that might do it, but the faq gives us:

# >> macros
# list here all the libraries your RPM installs
%define __requires_exclude ^libFoo|libBar|libFooBar.*$
# << macros

And states unequivocally that every library has to be listed. I could simplify, but I’m not certain I can trust the docs. I guess I could rip out the make files and do it by hand. Oh. boy.

#10

Ah, something like this can be done in the YAML as well:

Yaml:

Macros:
    - '__requires_exclude;^libFoo|libBar|libFooBar.*$'

Note the semicolon to separate name and values. There is also a Macros2 keyword which I never used, but I think it puts the macros in a later position in the spec file.

#11

Ah, thanks! I was looking for that and believe it’s exactly the semi colon that I neglected!

#12

If I have a macro (from yaml, this works!)

  • ‘__requires_exclude;^libfreetype|libjpeg|libopenjp2|libtiff|libfreetype.*$’

I ‘only’ get messages about 'my libraries:
_imagingmorph.cpython-37-arm-linux-gnueabihf.so and co.

if i require_exclude ‘my libraries’ I get even more errors. Should I include my libraries AND the linked?

#13

Not sure about that last one, I never had to do that.

But in yaml you can also give the NoAutoReq directive, which will turn off all that requires stuff, and leave you to handle it yourself. Maybe that’s an alternative option?

#14

That sounds like the right direction. Which documentation are you reading?

#15

lol, basically the spectacle README really.

Plus having been through some of the hoops myself, although never with very complcated software, and never trying to be harbour compatible.

#16

Oh. Dear. I’ve been reading the wiki page. Ah well, thanks for the Ghibli Ambience, btw!

#17

hehe, you’re welcome.

Doing ambiences is whre I got my feet wet with rpmbuild. Then move on to spec files, and eventually yaml.

As I don’t do c++, never had to deal with pro files myself, except for packaging other people’s work.