Provide dependency installabitlity check

[lachmanfrantisek]

User story: As a package maintainer doing a package rebase, I would like to check if dependencies of my package can be installed so the new update does not cause issues to users of packages depending on my package.

Maybe as a part of #12 , or the default installability check or a separate plan, we can provide a check to install dependent packages together (or after?) the newly build RPM.

For the start there can be an env.var. or other way for user to specify the list of such packages. We can also (maybe as a default) check all the dependencies, but this does not need to be implemented from the very start.

[LecrisUT]

Would make sense to be on the Fedora-CI installability as an additional input. Curious though, how would such installability fail at the RPM install stage?

[lachmanfrantisek]

Just to cross-link, I've created a separate issue for builds: https://github.com/packit/packit-service/issues/2343

[lachmanfrantisek]

Curious though, how would such installability fail at the RPM install stage?

Like, how it's possible? Packages can specify version requirements that can collide. Or, just some mess on the file level?

Ideally, a smoke test (not sure how and where to define) can help to be really sure we are not breaking anything.

[LecrisUT]

I think those are partially covered by rpminspect ABI check and rpmdeplint

[penguinpee]

Curious though, how would such installability fail at the RPM install stage?

Like, how it's possible? Packages can specify version requirements that can collide. Or, just some mess on the file level?

Python packages are quite notorious for this. Especially, if you have different releases in rawhide and stable branches (pre-release vs. stable release).

I think those are partially covered by rpminspect ABI check and rpmdeplint

In the case of Python packages, it's usually not ABI that breaks. It's more upstream piining dependencies to a specific version. Sometimes minimum, sometimes maximum, sometimes even both.

I'll take a look if rpmdeplint could be of help.

[LecrisUT]

See this comment for links on rpmdeplint

[penguinpee]

User story: As a package maintainer doing a package rebase, I would like to check if dependencies of my package can be installed so the new update does not cause issues to users of packages depending on my package.

To elaborate a bit. With Packit a lot of work regarding package updates is automated. I receive a PR for one of my packages, I take a look at the results, all looks fine, I merge, build, go to bed and wake up to an FTI/FTBFS notification on another package I maintain.

Turns out the updated package no longer falls within the limits set by the dependent package. Say foo<=1.10 and I just updated foo to 1.11.0. If that is a runtime (install) dependency only, it will not be discovered by any of the current mechanisms I know of. I need to know exactly what depends on my package and what the version constraints are.

Knowing what depends on your package is not too hard to find out. But it gets more elaborate if you need to find out what the version constraints are, if any.

For the start there can be an env.var. or other way for user to specify the list of such packages. We can also (maybe as a default) check all the dependencies, but this does not need to be implemented from the very start.

For starters I'm fine with manually specifying. But ultimately this should be auto discovered, since dependencies are dynamic. New packages are added to Fedora all the time. Existing packages add and remove dependencies as well. Manually keeping a list up to date is error prone.

I'm not sure how the current FTI discovery works. I believe it's something Koschei does. Maybe there's some inspiration to be found there.