Re: When is a file dependency appropriate?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Dne 06. 10. 22 v 14:18 Panu Matilainen napsal(a):
On 10/6/22 11:55, Vít Ondruch wrote:

Dne 06. 10. 22 v 9:18 Otto Liljalaakso napsal(a):
Miro Hrončok kirjoitti 6.10.2022 klo 2.33:
On 06. 10. 22 1:21, Otto Liljalaakso wrote:
Recently, I have run into some cases where file dependencies like Requires: /usr/bin/foo are used.

In a recent thread on this mailing list [1],
it is mentioned that such Requires should be avoided,
because resolving file dependencies requires a large amount of memory.

I don't believe that resolving file-Requires from directories listed at [2] from your email is more memory hungry. Where exactly was that said?
[1]: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/CRREDQUPPJYWVRMA4DOKYU2KZZLKC4D5/ [2]: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_dependencies



Maybe I should have re-read the thread closely before posting,
because the most relevant message is this [3]:

"
The discussion in the bug indicates that this memory growth is related to
loading of the full filepath dataset. We have been discussing splitting
out the non-primary-filepath-data (i.e. paths that are not /etc, /usr/bin,
/usr/sbin), out into a separate lazilly-loaded file. If we manage to do
that, we'll kill two birds with one stone:

- initial download of repo metadata on every freakin' dnf operation can
  go down from 80 to 20 MB
- the peak memory use will go down
"

Which exactly confirms what you say.

I am still wondering a bit if there is something else bad about file dependencies?


If I am not mistaken, in the YUM days, the file list was split into two parts. One list contained several high profile directories such as /usr/bin [1] while the other contained everything. By default YUM have not loaded the full file list by default, just the short one. The data were not loaded by default. But AFAIK, DNF always loads everything and it does not look that this would change. This is one BZ which comes to my mind for a reference: https://bugzilla.redhat.com/show_bug.cgi?id=968006

IOW for your example, the file dependency was always supported (and IMO preferable). It probably does not matter these days, unless you really consider memory consumption (and I don't think we should generally avoid the file dependencies just on the base of memory consumption).

In the yum days, certain locations of the file list, such as /usr/bin were embedded in the main data. They're still there, look for <file> entries in primary.xml.


This is good point. I have already forget the details. So if there was embedded just the right amount of information in the main data, we would not need the full list (and lazy loading). Currently, the data contains e.g. /usr/bin/*, which is useful for installing `/usr/bin/foo`. But we know that in the repository, there is RPM with `Requires: /some/strange/path`. Therefore during creating the repository metadata, we could look for RPM providing this path and include it into the main metadata. This would blow the metadata a bit, but it would allow to not care about the full file list at all. Of course that would mean `dnf install /some/random/path` won't work universally, but 1) I don't think this is widely used for random stuff 2) it is easy to detect and download the full file list instead if needed.

Should I open request against createrepo_c?


Vít



I don't know if libsolv/dnf look at that data at all, the architecture is so drastically different compared to yum that the seemingly obvious lazy loading may well be very very difficult to achieve. I remember that being the case with apt-rpm (if anybody remembers *that* old beast) whose operational model was closer to libsolv than yum.

    - Panu -

    - Panu -


_______________________________________________
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

Attachment: OpenPGP_signature
Description: OpenPGP digital 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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux