Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

include --noorder option to rpm install when accumulation is enabled … #568

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

koomie
Copy link

@koomie koomie commented May 14, 2020

…in order

to preserve project Order declarations.

Signed-off-by: Karl W. Schulz [email protected]

…in order

to preserve project Order declarations.

Signed-off-by: Karl W. Schulz <[email protected]>
@koomie
Copy link
Author

koomie commented May 14, 2020

Motivation here is to honor project configuration Order stanzas when DO_CUMULATE=true. Otherwise, the multi-package rpm install will reorder the install package ordering (at least, this is observed with Leap 15.1).

@adrianschroeter
Copy link
Member

Esp. for SUSE distros this should be fixed in the distro instead.

It makes the build incompatible btw, so we could only introduce this only via a flag.

But it is a bit questionable if we really need this (in first place it would be a workaround for broken packages)

@koomie
Copy link
Author

koomie commented May 15, 2020

Agree that this is not an issue with the distro packages. However, the cumulate option is enforced for all packages necessary for a particular build. In OpenHPC's case - we pull in some 3rd party packages we don't control (vendor compilers) that don't have their dependencies defined 100% correctly. To resolve, we have historically taken advantage of the Order option in an OBS project config, but the problem with the current code is that package Order specifications are silently ignored when cumulate is triggered. It looks to me like the RPM package list is initially ordered correctly to honor any Order specifications and that's why I suggested a simple fix with the --norder addition.

Maybe another possibility for those who rely on the Order option is to provide an option to the project admin to disable cumulate. Right now it is hard coded via:

    typeset -ri suse_version=$(chroot $BUILD_ROOT rpm --eval '%{?suse_version}' 2>/dev/null)
    if ((suse_version > 1220)) ; then
        DO_CUMULATE=true
    fi

Or, perhaps there is no interest in maintaining support for the Order option with newer suse distro's - in that case perhaps updating the documentation to say that it does not work with suse_version > 1220 would be helpful? (it would have helped clue me in to why our dependency chains were broken on Leap but not CentOS).

Thanks for the consideration.

@mlschroe
Copy link
Member

It does work with newer suse distros. It was added because some distros had missing dependencies, it works in that case even without --noorder because rpm does not touch the command line order if there is no dependency.

You seem to need another use case, because you want to get rid of some existing dependency. I'm curious why it is there, and why it is wrong.

If you absolutely need this functionality we can add a BuildFlag: rpmnoorder to enable --noorder installs. Cumulating is still needed for some packages like tetex that rely on the posttrans script being called after all tetex packages are installed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants