On Thu, Oct 6, 2022 at 2:51 PM Vít Ondruch <vondr...@redhat.com> wrote:
> > Dne 06. 10. 22 v 14:38 Kalev Lember napsal(a): > > On Thu, Oct 6, 2022 at 11:05 AM Vít Ondruch <vondr...@redhat.com> 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: > > https://github.com/rpm-software-management/rpm/issues/721 > > https://github.com/rpm-software-management/rpm/issues/1850 > 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
