#2560 Please, allow me to update rpkg-macros to 2.0 in epel and fedora releases
Closed: Accepted 3 years ago by zbyszek. Opened 3 years ago by clime.

Hello,

I would like to update rpkg-macros to version 2.0 in epel and Fedora releases. There is a backward incompatible change: https://pagure.io/rpkg-util/c/280343176796be54686f84a677f5744027ce84e9?branch=master

Actually, it's rather a bugfix but in theory, it can have an effect on some use-cases. This tooling is packager specific and still mostly unused, so I would like to fix it while I can still do it without any impact.

clime


What is the effect of this change, in simple terms?

What is the effect of this change, in simple terms?

It changes the location based on which state variables like GIT_ROOT, GIT_HEAD, ... (https://pagure.io/rpkg-util/blob/master/f/macros/macros.d/git.bash#_122) are derivered.

Before the git state was derived from CWD, now it's from the directory where the spec file being preprocessed is located.

If one is using git_dir_* macros (the recommended ones) - these basically always operate on the directory where the spec file is located and if the global state was derivered for some foreign git repo, they will error out. That's why I needed to do this: https://pagure.io/preproc-rpmspec/blob/170f5b859704dcaf63f9b5f3f047ec439da545e3/f/preproc-rpmspec#_146 - basically any tool invoking preproc on a file with git_dir_* macros needs to switch CWD first (before preprocessing) to the target git repo where the spec file is located. That shouldn't be needed - providing correct INPUT_PATH to preproc should be enough to process a file with git_dir_* macros from anywhere on filesystem.

It was done like this originally to allow for use-cases where the spec file is placed outside of a git repo you want to operate on. So you can have spec file e.g. in a separate repo than the sources or you can have a generic spec file somewhere on filesystem for projects that use the ./configure; ./make; ./make install procedure and therefore you could use such spec file for any of them to create srpm/rpm. It assumed git_cwd_* macros are used in the spec file - these macros are bound to the current working directory (instead of directory where the spec file is located as is the case for git_dir_* macros).

These use-cases only work with git_cwd_* macros if the git state is initiated from CWD (original behavior of rpkg-macros), therefore after this change, it will no longer work.

But these use-cases wouldn't e.g. work with preproc-rpmspec (or some other tooling anyway) because these tools need to change CWD to the repo where the input spec file is located in case the spec file contains git_dir_* macros.

Either git_cwd_* macros should have a separate global git state (the state is there to assure consistent processing of the macros in time in case the repo is being changed meanwhile) based on CWD or there should be a new type of macros (e.g. src_git_pack, srt_git_archive, maybe src_git_version) that use a separate state/context generated based on SOURCE_GIT_REPO environment variable (or similar). Any ideas or comments welcome.

Maybe give me more time here. There should be a clear idea how to cover those use-cases that were originally intended to be covered by the git_cwd_* macros.

It seems that this will have limited impact, since the number of users is low. I think you're in the best position to judge the impact.

+1

+1 for Fedora.

We have no power over EPEL here.

+1 to what @churchyard says.

make that +2 :)

+1 and you can reach the epel steering folks on epel-devel and/or pagure.io/epel

Metadata Update from @churchyard:
- Issue tagged with: updates policy exception

3 years ago

APPROVED (+7, 0, 0) for Fedora. EPEL should be handled on epel-devel and/or pagure.io/epel.

Metadata Update from @zbyszek:
- Issue tagged with: pending announcement

3 years ago

Metadata Update from @zbyszek:
- Issue untagged with: pending announcement
- Issue close_status updated to: Accepted
- Issue status updated to: Closed (was: Open)

3 years ago

Login to comment on this ticket.

Metadata