Offer more replacements than just the package's version

[Vogtinator]

While it obviously goes against the package's name, it would be useful to have the package's %{description}, %{summary}, %{license}, %{url}, etc. available as replacements as well.

[davidcassany]

You mean grabbing this values form an rpm metadata and use them as values for replacement? I guess it should be possible.

Probably sorting out a better name (and see the pros and cons of the change) is something that could be discussed after a round of new features.

[Vogtinator]

Yup, this would make #4 more relevant.

[akshat5302]

I would like to contribute to it could you just elaborate the issue @Vogtinator @davidcassany

[dcermak]

@akshat5302 At the moment the service offers to find the version of a package in the buildroot and insert it in the build recipe file. For example, given this _service file:

<service name="replace_using_package_version" mode="buildtime">
  <param name="regex">%%TAG%%</param>
  <param name="package">mariadb</param>
</service>

the service would then look for the package mariadb, fetch its version, look for the build recipe in this package (e.g. if this was a rpm package, that would be the spec file) and replace %%TAG%% in the build recipe with the version of mariadb.

Now this feature request is about allowing to extract additional information from the mariadb package, not only the version, but also other metadata of the rpm package, e.g. the description.

You generally get these metadata via rpm:

f4f0280b5e5f:/ # rpm -q --qf "%{DESCRIPTION}" mariadb
MariaDB is an open-source, multi-threaded, relational database management
system. It's a backward compatible, drop-in replacement branch of the
MySQL Community Server.

This package only contains the server-side programs.

To get this in, you'd have to add a new command line flag to replace_using_package_version.py that would allow to specify which metadata to extract.

Does that help you out a bit? If anything is unclear, please don't hesitate to reach out.

[akshat5302]

Should I have to create new function for different metadata like this one:-

def get_pkg_version_from_rpm(rpm_file):
    command = [
        'rpm', '-qp', '--queryformat', '%{VERSION}', rpm_file
    ]
    return parse_version(run_command(command))

Which you have created to fetch package version from rpm

[dcermak]

No, I wouldn't create a separate function for each metadata that we want to fetch, as that will be essentially the same call every time. The only difference will be the string after --queryformat.

[akshat5302]

And that string we can take as input from user and put that in %{} block which kind of metadata they want to see from rpm package I think so

[dcermak]

Yes, but we really should limit the allowed input to a few sensible options (e.g. version, description, epoch), as the user shouldn't be allowed to inject arbitrary strings here (that could even lead to vulnerabilities).

[akshat5302]

Yes and how could we stop them ??

[dcermak]

By only allowing some values via the docopt cli parser: http://docopt.org/ and by checking that the replacement is in an allowlist.

[akshat5302]

I'm interested in it please assign this issue to me

[dcermak]

If you want to work on this simply open a pull request, assigning the issue to you will not change a thing ;-)

[akshat5302]

Yes sure 😊

[dcermak]

@akshat5302 In case you are still interested in working on this issue and are stuck or want help, feel free to reach out for guidance. No pressure from my side though, feel free to proceed at your own pace.

[akshat5302]

@dcermak sorry for that much delay actually that University exams sucks everytime when you want todo good they had taken exams and then after exams they made me busy in giving workshops to juniors so I was busy in that but from today itself I'm free and will do work on that issue