PR 4297

The link suggests that packages shouldn't have to make changes for this.

The definition of %_sbindir will be changed to %_bindir, so packages will start using the new directory after a rebuild without any further action. Maintainers may stop using %_sbindir, but don't need to.

Can you clarify what is failing in our case?

Yes, PR is not correct now. Jana will file a new one tomorrow. What is failing is the part where we're replacing python2 shebangs. buildroot contains /usr/sbin paths while sbindir is /usr/bin. So, just fixing that part would be enough.

Well here's an example of the problem (or at least a problem stemming from the change)
https://bugzilla.redhat.com/show_bug.cgi?id=2340700

From root.log for https://koji.fedoraproject.org/koji/taskinfo?taskID=127994657

+ make DESTDIR=/builddir/build/BUILD/koji-1.35.1-build/BUILDROOT PYTHON=/usr/bin/python3 install
mkdir -p /builddir/build/BUILD/koji-1.35.1-build/BUILDROOT//usr/share/koji
for p in schema-update-cgen.sql schema-update-cgen2.sql schema-update-dist-repos.sql schema-upgrade-1.10-1.11.sql schema-upgrade-1.11-1.12.sql schema-upgrade-1.12-1.13.sql schema-upgrade-1.13-1.14.sql schema-upgrade-1.14-1.15.sql schema-upgrade-1.15-1.16.sql schema-upgrade-1.16-1.17.sql schema-upgrade-1.17-1.18.sql schema-upgrade-1.18-1.19.sql schema-upgrade-1.19-1.20.sql schema-upgrade-1.2-1.3.sql schema-upgrade-1.20-1.21.sql schema-upgrade-1.21-1.22.sql schema-upgrade-1.22-1.23.sql schema-upgrade-1.23-1.24.sql schema-upgrade-1.24-1.25.sql schema-upgrade-1.25-1.26.sql schema-upgrade-1.27-1.28.sql schema-upgrade-1.28-1.29.sql schema-upgrade-1.29-1.30.sql schema-upgrade-1.3-1.4.sql schema-upgrade-1.30-1.31.sql schema-upgrade-1.31-1.32.sql schema-upgrade-1.32-1.33.sql schema-upgrade-1.33-1.34.sql schema-upgrade-1.34-1.35.sql schema-upgrade-1.4-1.5.sql schema-upgrade-1.6-1.7.sql schema-upgrade-1.7-1.8.sql schema-upgrade-1.8-1.9.sql schema-upgrade-1.9-1.10.sql schema.sql ; do \
    install -p -m 644 $p /builddir/build/BUILD/koji-1.35.1-build/BUILDROOT//usr/share/koji/$p; \
done
+ popd
~/build/BUILD/koji-1.35.1-build/koji-1.35.1
+ scripts='/usr/bin/koji /usr/bin/kojid /usr/bin/kojira /usr/bin/koji-shadow
         /usr/bin/koji-gc /usr/bin/kojivmd /usr/bin/koji-sweep-db
         /usr/bin/koji-sidetag-cleanup'
+ for fn in $scripts
+ sed -i 's|#!/usr/bin/python2|#!/usr/bin/python3|' /builddir/build/BUILD/koji-1.35.1-build/BUILDROOT/usr/bin/koji
+ for fn in $scripts
+ sed -i 's|#!/usr/bin/python2|#!/usr/bin/python3|' /builddir/build/BUILD/koji-1.35.1-build/BUILDROOT/usr/bin/kojid
sed: can't read /builddir/build/BUILD/koji-1.35.1-build/BUILDROOT/usr/bin/kojid: No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.SEEdeK (%install)
RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.SEEdeK (%install)
Child return code was: 1

Question is if it is safe to stay with /usr/sbin directory. I'm inclining to yes as some paths could be used in cronjobs (koji-sweep-db, etc.) and could introduce unnecessary compatibility issues. @mikem ?

Other platforms we care about still have (separate) sbin. I don't think we should remap all these paths based on rawhide. It doesn't sound like they intend this to force package to make sweeping changes.

Can you not just conditionalize things for f41+ ? On f41+, just install only into bindir, otherwise keep the current behavior...?

Can you not just conditionalize things for f41+ ? On f41+, just install only into bindir, otherwise keep the current behavior...?

What I'm a bit afraid here is that someone has e.g /usr/sbin/koji-gc invocation in customized cronjob which would stop to work in such case. So, continuing using /usr/sbin seems to more a bit more compatible. We could do the conditionals in the moment when Fedora decides to leave sbin dirs completely.

@mikem ?

That shouldn't be an issue from my understanding.

For people who upgrade the filesystem package will make links of anything that was in sbin and moves to bin.

For people who do fresh installs, sbin will just be a link to bin

So, I would suggest modifying the Makefile to allow passing SBINDIR or whatever, default to /usr/sbin.
Then in the spec pass SBINDIR=/usr/bin for f41+ (also conditionalizing files)

At least I think that should work...

What I'm a bit afraid here is that someone has e.g /usr/sbin/koji-gc invocation in customized cronjob which would stop to work in such case. So, continuing using /usr/sbin seems to more a bit more compatible.

Fedora will have sbin -> bin as a symlink, right? So /usr/sbin/koji-gc will continue to work.

I think breaks from this will be more esoteric. We should collect the actual problems that are occurring and fully understand what is going wrong before we attempt to fix things. This change in Fedora is not supposed to break packaging.

Heh, are other packages seeing issues like this? I can't imagine we're the only ones here.

The root cause of ours is that, while we have long referenced %{_bindir} and %{_sbindir} in the spec because it seemed more correct, we have not actually parametrized the installation to honor these values. Files are placed at build time by make install which does not know about these macro values.

In light of that, I think we have two paths forward:

1. stop using %{_bindir} and %{_sbindir} in the spec and use the paths that make actually installs to. #4297 almost does this, but not quite
2. parametrize our install to handle this variation

yeah, it's affecting any packages that are hard coding sbindir.

Yep. I think parameterizing makes the most sense, then the spec can pass the right thing for both f42+ and all the older releases via conditional...

I suppose it could even just default to the old path's and only change if the parameter is passed?

Commit 28159f6a fixes this issue

Commit f67b9db8 fixes this issue

Note that this results in the base koji package having duplicate's of all the things in %{bindir} because there's:

%{_bindir}/*

and everything moved to it.

I guess it 'works', but it's a bit weird to see kojid in the base package.

So, either those wildcard bindirs need changing or perhaps we could use https://pagure.io/koji/pull-request/4324 instead?

Note that this results in the base koji package having duplicate's of all the things in %{bindir} because there's:
%{_bindir}/*

Does it? I don't get that when I build an rpm locally from master branch.
PR #4297 adds %exclude /usr/sbin under %files

I'm ok with pushing #4324 (or #4335) forward, but I don't seem to be able to reproduce this issue

Perhaps I screwed up something in my testing, but since you link /usr/sbin to /usr/bin and then install, everything is in /usr/bin and the %{bindir} means you get:

✗ rpm -qlip /var/lib/mock/fedora-rawhide-x86_64/result/koji-1.35.2-1.fc43.noarch.rpm| grep bin
/usr/bin/koji
/usr/bin/koji-gc
/usr/bin/koji-shadow
/usr/bin/koji-sidetag-cleanup
/usr/bin/koji-sweep-db
/usr/bin/kojid
/usr/bin/kojira
/usr/bin/kojivmd

@kevin

If I use the PR branch and make a local rpm, I get

[mikem@localhost koji]$ git log --oneline --decorate -n 2
ae04a1169 (HEAD -> pagure/pr/4297, jlibrova/issue-4296) koji.spec sbindir is now bindir
b7d193c41 PR#4021: newRepo: support hints for oldrepo value
[mikem@localhost koji]$ make rpm
...
[mikem@localhost koji]$ rpm -qlip /home/mikem/Devel/koji/koji/noarch/koji-1.35.1-1.noarch.rpm |grep bin
/usr/bin/koji

Does your spec include the %exclude /usr/sbin under %files?

For that matter, does #4335 actually work better for you?

@kevin if this is still a problem, maybe we could switch to #4338 since this one is closed.

Sure, I have been meaning to do some testing, but keep getting sidetracked. Will continue there.

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/koji/koji/issues/4296

Please continue any further discussion there.