SDK / spectacle deletes custom macros in RPM spec

Bug Reports
#1

REPRODUCIBILITY (% or how often): always after changing harbour-<app>.yaml
BUILD ID = OS VERSION (Settings > About product): SDK 3.8.3
REGRESSION: No

DESCRIPTION:

When the RPM spec file is re-generated after any change to an app’s yaml config file, the custom # >> macros section is cleared. I use this section as per the Harbour FAQ to appease the Harbour validator script when using bundled QML modules.

This means I have to “build, fix spec, build again” instead of just “build once” after (e.g.) updating the version number in yaml.

STEPS TO REPRODUCE:

  1. open a project in QtCreator that bundles QML modules, e.g. https://github.com/ichthyosaurus/harbour-file-browser
  2. change anything in the app’s rpm/harbour-<app>.yaml file, e.g. Release:
  3. build the app
  4. notice that RPM validation fails
  5. re-add %define __provides_exclude_from ^%{_datadir}/.*$ to the spec file
  6. build again

EXPECTED RESULT:

spectacle should never change custom sections like # >> macros. I don’t know if the bug also affects other sections like # >> setup.

ACTUAL RESULT:

Everything in between # >> macros and # << macros is deleted when re-generating the spec file.

#2

This is exactly why I removed all yaml files (almost) for all projects. I have a feeling they are being silently deprecated.

1 Like
#3

Isn’t the SDK complaining when the yaml file is missing? I remember there was some reason to keep these files…

#4

No. Removing the yaml files is just an advantage. Only one ‘extra’ build file :wink:

Well, even if it ‘complains’, given the number of warnings (cough), my c++ produces, it’s not showing up on my radar. And it doesn’t effect the building of rpms, nor any other part of the build.

#5

Just did 2 test builds. Neither of them seemed to care in the least about the yaml files. One was a QML only app, the second a subdirs c++ project with static library.

I think you can say, be gone!

#6

Yes I have seen this happening since forever.

What does work is having a Macros2: key in the yaml, e.g.

Macros2:
  - 'foo;bar'

and adding

# << macros2
... my macros
# >> macros2

but macros2 comes just before %prep so doesn’t work for everything.

#7

So, a question. What is the purpose of the yaml files? They seem to be completely redundant. The spec files, on the other hand, must be there to build rpms?

#8

I think there existance is mostly historic, from mer/MeeGo.

I do like some parts spectacle does, from keeping spec files similar in structure, to handing of little details like subpackage dependencies etc.

#9

There seems to be a bug with preserving content between the “macros” placeholders. “macros2” works as expected. Anyway in your case you can simply move macro definition to the YAML, using any of (or both) the “Macro” and “Macro2” keys. The former one ends just after “Name:”, the latter just before “%prep”.

Macros:
    - __provides_exclude_from;^%{_datadir}/.*$

YAML-based package specification was introduced to allow tools to edit the package specification with moderate effort. RPM SPEC in general is too complex for tool assisted editing. So the limited expressiveness of YAML is intentional, keeping you the possibility to maintain manual additions to the generated SPEC as long as they are encapsulated withing the ‘>>…<<’ markup.

YAML is also fully optional. If your packaging needs more complex SPEC changes that do not fit between any of the recognized ‘>>…<<’ pairs, you can drop the YAML.

3 Likes
#10

Thank you all for the helpful replies. I just noticed someone added the tag “tracked” to the thread; that’s a good sign, I suppose :).

#11

Spectacle is also open source, and just python, someone who speaks parsletongue may submit a PR…

1 Like
#12

I did not know that, thanks! After a quick glance at the template code I may have found one possible bug. I cannot test it though…

#13

Misusing YAML for the win!

I have found the following trickery works even with the buggy spectacle version:

YAML:

Macros:
  - 'mymacro;1'
  - |
    dummymacro; dummyparameter
    %if 0%{?sailfishos_version} >= 40400
    %define my_macro_for_4.4 foo
    %else
    %define my_macro_for_others bar
    %endif

gives in spec:

# >> macros
stuff in here will be deleted
# << macros
%define mymacro 1 
%define dummymacro dummyparameter
%if 0%{?sailfishos_version} >= 40400
%define my_macro_for_4.4 foo
%else
%define my_macro_for_others bar
%endif

Using this pattern you can basically customize the whole head of your .spec.

#14

This one I’ve begun to abuse :slight_smile: Thanks for the insights!

#15

And in honour of @ichthyosaurus and large sea fairing creatures with big teeth: Giant ichthyosaur’s huge tooth points to sea creatures with robust bite | Palaeontology | The Guardian

1 Like