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_dependenciesMaybe 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 toloading of the full filepath dataset. We have been discussing splittingout 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=968006IOW 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@xxxxxxxxxxxxxxxxxxxxxxxFedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelinesList 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
