On Wed, 2 Sep 2020 at 12:13, Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:
Hello,
an interesting problem has been reported in Bugzilla 3 years ago:
https://bugzilla.redhat.com/show_bug.cgi?id=1486468
tl;dr There are generated files in /usr/share/mime without owning packages.
When update-mime-database database is run (by RPM trigger), files are generated
in /usr/share/mime, such as:
/usr/share/mime
├── XMLnamespaces
├── aliases
├── application
│ ├── andrew-inset.xml
│ ├── annodex.xml
│ ├── ...
│ └── zstd.xml
├── ...
├── x-content
│ ├── audio-cdda.xml
│ ├── ....
│ └── win32-software.xml
└── x-epoc
└── x-sisx-app.xml
The files are generated based on content form multiple packages. I.e.
shared-mime-info cannot list all the files as %ghosts because the list of files
is volatile.
As a specific example, on my system, I have:
/usr/share/mime/application/x-openscad.xml
/usr/share/mime/packages/openscad.xml
The file in packages/ is shipped and owned by the openscad package.
The file in application/ is generated by update-mime-database.
So I guess the questions are:
Should shared-mime-info %ghost all files created by update-mime-database when
only shared-mime-info is installed? (That seems to be easy enough).
Should individual packages shipping mime files %ghost the files generated from
them? E.g. should openscad %ghost /usr/share/mime/application/x-openscad.xml?
Is there a better (possibly automated) way of doing it? Or is it not worth it
and we simply say that the files are OK not being owned?
I'd be in favor of option #1 - make shared-mime-info %ghost the /usr/share/mime dir.
Regarding openscad (and other packages providing mime files), does it then need to
Requires shared-mime-info explicitly?
Option #2 would require extra leg work here and there. Also, it might entail a packaging-wide
expectation that packages providing mime info should %ghost /usr/share/mime.
_______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-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/packaging@xxxxxxxxxxxxxxxxxxxxxxx
