V Wed, Dec 04, 2024 at 11:08:43AM +0100, Mikel Olasagasti napsal(a): > Hau idatzi du Petr Pisar (ppisar@xxxxxxxxxx) erabiltzaileak (2024 abe. > > I don't like it: First, any time a subpackage of git adds or moves a subcommand > > one would have to reevalutate all the reverse dependencies. > > > > Second, your proposal abuses packagers by unnecessary pull requests. You > > should first check whether changing the dependency makes sense and only if it > > does, open the pull request. > > I think I was not clear enough in the proposal, sorry about that. > > The idea is not about opening PRs on day0 if change is approved > without any testing. PRs would be created only after testing that > build works in the case of the specs that have it as part of BR, and > testing the package for those that have it as requirement. > > I'll update the wiki with this information. > > > Third, your change does not mention checking spec files for comments that > > "git" is explicitly required because "git-core" is not enough. Some people > > already did the excercise. > > Correct. This should be more clear in the proposal as commented in > previous point. > Thanks. > > I'd rather see a different approach: > > > > Add RPM Provides corresponding to git subcommands to respective git > > subpackages and change dependencies on git to the provides. > > > > E.g. packages executing a "git send-email" command would depend on > > "git(send-mail)" instead of "git". > > > > BTW, it seems that "git send-email" is broken in Rawhide: Having installed > > git-2.47.1-1.fc42.x86_64 package, the subcommand is not available. > > Interesting approach, but this would require also changes in depending > packages right? A package that required git because git-core is not > enough would need to be updated. > In the long-term to take the benefit of subcommand-oriented dependencies, yes. -- Petr
Attachment:
signature.asc
Description: PGP signature
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
