search

rpm-software-management / dnf5

Next-generation RPM package management system
Other
225 stars 76 forks source link

Add `source-install`/`si` command (installs build dependencies and unpacks SRPM for building in one step) #1208

Open Conan-Kudo opened 5 months ago

Conan-Kudo commented 5 months ago

This mimics a feature that exists in other RPM package managers that makes it simple to quickly start working with an RPM in a development or container environment context.

Alternatively, instead of a source-install/si subcommand, a --source option that applies to various subcommands would work too (similar to --forcearch). However, I suspect it'd make sense as a source-install/si command because it will need to implement similar behaviors to an eventual debuginfo-install subcommand where -source repos are turned on momentarily and automatically to be able to get the source package.

In particular, both Zypper (zypper source-install/zypper si) and URPMI (urpmi --install-src) have this feature. When run as non-root, the build dependency installation part is should be skipped automatically.

This is important for the successful adoption of DNF by openSUSE and Mageia.

ppisar commented 5 months ago

Do you expect upgrade, remove and other commands which change installed packages to maintain the installed source packages either? Or would a loose maintenance in the sense of debuginfo packages (i.e. no upgrades of source packages) be enough?

Do you realize that dependencies listed in source package generally do not match dependencies computed from the packaged spec file?

Conan-Kudo commented 5 months ago

Do you expect upgrade, remove and other commands which change installed packages to maintain the installed source packages either? Or would a loose maintenance in the sense of debuginfo packages (i.e. no upgrades of source packages) be enough?

I think "loose maintenance" is sufficient.

Do you expect upgrade, remove and other commands which change installed packages to maintain the installed source packages either? Or would a loose maintenance in the sense of debuginfo packages (i.e. no upgrades of source packages) be enough?

Do you realize that dependencies listed in source package generally do not match dependencies computed from the packaged spec file?

I'm counting on it. Dynamic build dependencies are stored in the SRPM and don't exist in the spec file.