You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the unpacked source area, patches becomes a symlink to .. , but the .pc/ folder is the same as usual.
It would be nice if this is re-implemented using python from the ground up, not using rpm cmdline tools like quilt does.
setup has two modes, slow and fast, but the differences don't seem to be especially relevant for a Python rewrite. It looks like we would use the slow approach if not using rpmbuild.
The guts of the spec reading is done with, where fuzz factor is a setup command line option
My guess is that we can do most of the setup without rpmbuild if we can parse the spec fairly reliably.
The library most used for .spec reading seems to be https://github.com/bkircher/python-rpm-spec .
IMO that would be preferred, even if setup is not quite complete, or as accurate/fast/etc .
The text was updated successfully, but these errors were encountered:
I had a quick look at the setup command. Can't say I understand it's purpose yet because I am also not very familiar with rpm packaging. Could you explain the setup command in detail?
Sure. A rpm package workarea will typically consist of a spec, and some sources (tarballs) and patches. The sources and patches could be online, but there is a flag in rpm which blocks using online resources, so 99% of the time they are local.
The spec refers to the tarball and the patches, and is the only way to know which local tarball should be used, and the order of the patches.
When a new release of the software comes out, it is going to break some of the patches, so the most common use of quilt here is to freshen the patches by unpacking the new tarball, applying the patches in a series with a high fuzz factor, fixing each patch which is broken. Then build the tarball + refreshed patches, and repeat until it builds and passes tests.
The spec file uses its own strange templating language, and then also has a lua scripting language behind that. And running all of that is very slow. Ideally we avoid that.
99% of the time, the sources and patches in the .spec need only some quite basic parts of the template language working - variables & variable substitutions.
I'll first try to try bkircher/python-rpm-spec across a large collection of spec files to see if it can get the sources and patches info out fairly reliable.
A critical part of openSUSE's use of quilt is the
setup
command, especially supporting starting from a .spec file.You can see it mentioned at https://en.opensuse.org/openSUSE:Fixing_bugs and https://en.opensuse.org/openSUSE:Build_Service_Tutorial#Using_quilt
In the unpacked source area,
patches
becomes a symlink to..
, but the.pc/
folder is the same as usual.It would be nice if this is re-implemented using python from the ground up, not using rpm cmdline tools like
quilt
does.setup
has two modes, slow and fast, but the differences don't seem to be especially relevant for a Python rewrite. It looks like we would use the slow approach if not using rpmbuild.The guts of the spec reading is done with, where fuzz factor is a
setup
command line optionMy guess is that we can do most of the
setup
withoutrpmbuild
if we can parse the spec fairly reliably.The library most used for .spec reading seems to be https://github.com/bkircher/python-rpm-spec .
IMO that would be preferred, even if
setup
is not quite complete, or as accurate/fast/etc .The text was updated successfully, but these errors were encountered: