On Thu, Oct 6, 2022 at 2:51 PM Vít Ondruch <vondruch@xxxxxxxxxx> wrote:
Dne 06. 10. 22 v 14:38 Kalev Lember napsal(a):
On Thu, Oct 6, 2022 at 11:05 AM Vít Ondruch <vondruch@xxxxxxxxxx> wrote:
BTW re-reading the ticket and since there are talks about DNF5, maybe it
would be worth of reopening the discussion. I think we could generally
do better and I see two options:
1) There seems to be a way to download additional data if needed
2) The metadata we provide in reposotories could be better. I.e. instead
of providing full file list, it could be actually enough to collect just
the files of the interest. E.g. if there is somewhere `BR:
/usr/bin/foo`, then during preparation of repo data, there could be file
list with record for bar package, providing entry such as "/usr/bin/foo:
bar". This would probably not require any big changes in DNF IMHO.
One problem I have with `BuildRequires: /usr/bin/foo` is that it hardcodes the /usr/bin directory, which is the right thing to do when the program that uses foo invokes it with full /usr/bin/foo path, but not at all when foo is searched from PATH.
* I don't think that PATH plays a role here, because otherwise we will be back to discussion if and when we should use `env` in shebangs or not.
* We had this issue for SCLs before and I think there are some proposals such as:
Thanks!
This has been a bit of a pain point for flatpak builds in Fedora where the rpms are rebuilt for /app prefix. If a package that has `BuildRequires: /usr/bin/foo` but the package that provides foo is rebuilt for /app prefix, then we no longer have /usr/bin/foo but instead /app/bin/foo and the BR no longer finds the package providing foo. Using %{_bindir} doesn't help either because not all packages that are used for flatpaks are rebuilt for /app (some are part of the flatpak runtime and stay in /usr).
Maybe it would instead make sense to have an abstraction where instead of listing /usr/bin/foo in the repo data, we'd have 'Provides: executable(foo)' and then other packages could do 'BuildRequires: executable(foo)' instead? That would nicely solve the hardcoded path issue.
Not sure I like it or not (I would need to give it more thought), but if it was autogenerated ....
Yes, of course autogenerated, anything else would be crazy :) I'll need to give this some more thought myself, it was just a quick idea I got when reading this.
I guess a transition plan (if we make up our minds that it makes sense to do it) could be to first make sure the provides are autogenerated, then do a mass rebuild, let people try it out in their packages for 6 months, and then provenpackager-edit all of Requires/BuildRequires: /usr/bin/foo in the distro to the new format as at that point all of supported Fedora releases are going to have the provides.
After that, all of /usr/bin provides can be removed from the primary repo metadata (maybe after 6 more months to give time for 3rd party repos to catch up) and kept only in the extra filelists metadata.
--
Kalev
_______________________________________________ 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
