#130 automate dependencies patching
Closed: Won't Fix 2 years ago by decathorpe. Opened 2 years ago by dcavalca.

Add a flag (e.g. -P) that instead of dropping you into an editor, attempts to automatically fix dependencies for you. This could look something like this:

  • for each dependency, lookup the corresponding package on src.fp.o
  • if the version matches (using the same matching logic that the build process uses), all is well
  • if it doesn't, check if src.fp.o is older or newer
  • if newer, patch the dependency and move on
  • if older, print an error that src.fp.o should be updated (and have a flag to optionally override this in case it's temporarily needed for stuff like nix)
  • if the package is missing altogether, print an error as it'll need to be packaged

This obviously won't cover all cases, but it could help streamline some of the manual work that's currently required. Thoughts?


Add a flag (e.g. -P) that instead of dropping you into an editor, attempts to automatically fix dependencies for you. This could look something like this:

  • for each dependency, lookup the corresponding package on src.fp.o
  • if the version matches (using the same matching logic that the build process uses), all is well
  • if it doesn't, check if src.fp.o is older or newer
  • if newer, patch the dependency and move on
  • if older, print an error that src.fp.o should be updated (and have a flag to optionally override this in case it's temporarily needed for stuff like nix)
  • if the package is missing altogether, print an error as it'll need to be packaged

This obviously won't cover all cases, but it could help streamline some of the manual work that's currently required. Thoughts?

I'm not sure that this is a good idea, even if it's not on by default.

I've seen cases where patching dependencies actually didn't cause the build of the package to fail, but failed dependent packages - because the compilation failure was caused by code that was only enabled for the non-default feature set. So patching dependencies should probably always require some amount of human intervention, because things can and do go wrong in interesting ways if you just patch things to use newer versions.

As an aside, this check would probably also be reeeeeeeally slow.

  • src.fp.o does not provide package version information via API, so you'd have to check out all git repositories, or rely on mdapi - but mdapi also provides outdated or wrong information
  • alternatively, check rawhide repository metadata, but that might be out of date with actual buildroot contents because of lagging composes. even checking the koji build repository might not be enough if a package has been built very recently ...

However, checking if a package exists is relatively fast in comparison, and that could probably be easily implemented in a simple optional rust2rpm check.

Metadata Update from @decathorpe:
- Issue close_status updated to: Won't Fix
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.

Metadata