
On 11/17/20 9:26 AM, Ludwig Nussel wrote:
Neal Gompa wrote:
On Tue, Nov 17, 2020 at 8:18 AM Ludwig Nussel <ludwig.nussel@suse.de> wrote:
Quite some packages carry around sections like this:
#UsrMerge mkdir $RPM_BUILD_ROOT/sbin ln -s %_sbindir/foo $RPM_BUILD_ROOT/sbin/foo #EndUsrMerge
That was added years ago as preparation of replacing /bin, /sbin, /lib and /lib64 with a symlink and merging the content into their counterparts in /usr. I'm not sure how that was supposed to work in practice though. To actually get rid of resp disable that code even for testing one would have to modify a hundred packages.
So I'd like to replace those comments with a conditional, ie
%if !0%{?usrmerged} mkdir %buildroot/sbin ln -s %_sbindir/foo %buildroot/sbin/foo %endif
That doesn't yet answer the question when and how we finally do the /usr merge. However at least it would be possible to flip a switch via prjconf to stop building compat symlinks in a branch project then. Factory as of today would keep building the packages the way they are now, so no change in content at this point. Using the macro also paves the way to actually test a usr merged environment in staging in the future.
So unless there are better ideas I'd just go ahead and adjust all packages that have those symlinks.
I'd more be in favor of just ripping all that stuff out, but yeah, your plan makes sense.
Longer term sure. Right now you can't just rip out eg /bin/bash. That would immediately bring all package builds to a grinding halt :-) Others might cause more subtle breakage either for package builds or at actual installations. So I'm in favor of using a global switch that allows us to prepare packages without causing breakage for users and packagers and then test the whole thing in staging including openQA etc at some point.
Most, if not all of these are from me and there was a wiki once that tracked the packages. Yes using a global switch is a better approach. Before going down the path I'd say it might makes sense to reach consensus that this is going to happen first. The effort got stuck, at the time and then eventually dropped by me, based on some package maintainers not agreeing with the arguments made for the change to dropping /bin and others in favor of /usr based locations. Times have changed and maybe those maintainers have changed their minds or maybe we can have a greater initiative to move this along such that those maintainers cannot be in a position of being blockers. In any event the markers should make things easy to find which was really the original goal ;) Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Engineer LINUX Technical Team Lead Public Cloud rjschwei@suse.com IRC: robjo