rpmlint
rpmlint copied to clipboard
rpm-software-management
Forbid requires on filenames
(From http://rpmlint.zarb.org/cgi-bin/trac.cgi/ticket/45, pkarlsen@…)
As synthesis doesn't store package filenames, this will lead to difficulties installing these.
Changed 7 years ago by scop
status changed from new to closed resolution set to wontfix What's synthesis? Sounds like a defect in it, and forbidding something like "Requires: /usr/bin/texi2html" or "Requires: /usr/lib/mozilla/plugins" would sound plain wrong to me, ditto for file based BuildRequires?.
I'm not aware of issues like this in other rpm related tools, so if synthesis cannot be fixed, I suggest adding a patch to the rpmlint package shipped in Mandriva that implements this instead of kind of polluting the upstream rpmlint with such workarounds.
Changed 7 years ago by misc
Well, synthesis is this : http://qa.mandriva.com/twiki/bin/view/Main/SynthesisHdlist
and will I am not in favor of adding this, we could however add a check to compare Provides against a configurable regexp to detect such problem.
This would be useful to forbid linking against a old version of some library, etc etc.
Does it sound like a good idea ?
Changed 7 years ago by scop
Sure, why not. Maybe even better if there would be configurable options for all Requires, Provides, Conflicts and Obsoletes -- and maybe each a list of regexps so they don't become too long and hairy. Or maybe generalize even more and allow configuring lists of forbidden regexps for any tag?
By the way, the example in the synthesis link above contains some dependencies on eg. /bin/sh -- so it does contain some support for file based dependencies after all, no?
Changed 7 years ago by misc
status changed from closed to reopened resolution wontfix deleted The problem with synthesis is not it doesn't support file based Requires and Provides, it comes from the implementation and design.
In order to reduce the size of this type of index, information were removed ( like file list, changelog, complete description ). But, since packages use file based requires, the current code add these file as a provides if a packages in the repository ask for it :
pkg a.rpm requires /bin/foo pkg b.rpm contains /bin/foo, so in the synthesis, you will have a provides foo.
Problem comes when c.rpm, in another repository, requires /bin/bar, provided by packages b.rpm. The script creating synthesis for the main repository do not know that /bin/foo must be added to the provides list. So synthesis are not usables for this.
So, yes, synthesis should be reworked ( and also for other reason ). But another solution is to not take in account file in Provides/Requires, by policy, as this is slowing the dependancy solving process ( size of the provides list for a packages, etc ).
So I think such a check would help.
Regarding the forbidden value in tags, the problem is : if we do a completly configurable check, we cannot have a useful comment associated with it. and if we do precise check, we may duplicate code.
I prefer the configurable check.
Changed 7 years ago by scop
In case you're working on changing synthesis - the package repository metadata format which is already supported by quite a few depsolvers handles this case by stuffing all files into a separate file which is loaded (only) on demand. The most common files are in the primary metadata file. http://linux.duke.edu/projects/metadata/
Changed 7 years ago by pkarlsen@…
Package file lists are deliberately left out of synthesis to keep it's size minimal, so adding it to synthesis would be against the intention of leaving it out..
There used to be a check in rpmlint (or at least a policy), I'm unable to find it, but also AdamW confirmed that he remembered such a thing, so I guess that it's not just my imagination. I also think there was other reasons for such a policy, not sure about the exact reason either, but doing some googling on "file dependencies" +rpm reveals some.. So staying away from file depedencies is probably a good thing other than keeping synthesis as minimal as possible..
Changed 7 years ago by scop
File based dependencies are often the only choice (apart from leaving some dependencies out altogether) for those who have illusions of practical cross distro packaging ;)
Note also that rpmbuild autogenerates such dependencies (at least mine on FC does) for all used executable script interpreters - does whatever generates synthesis include all executables in the repository it is run against in it or maintain a list of "known interpreters" or something? What should rpmlint do, maintain knowledge about what are the exceptions to file/interpreter based dependencies too so it wouldn't produce false positives by flagging errors where it is known that synthesis actually does contain the corresponding file provides?
While I still think that a depsolver which cannot handle whatever dependencies rpm itself can is broken, the warning message could be useful for (micro-)optimization purposes on systems that do handle arbitrary file based deps - so no more objections apart from that I think it really should be a warning, not an error, and that there needs to be a sane way of avoiding noise from known good file based deps as well as a sane way to maintain that noise prevention mechanism. I don't have good ideas for that at the moment, though, but luckily there's addFilter("file-based-dependency") if everything else fails ;)
Changed 7 years ago by pkarlsen@…
Yes, they might be the only choice for cross distro packaging (just like statical linking;), but more important is what you say about it being an illusion. ;)
Third party packages trying to be distro neutral, they can use it as much as they want, but for Mandriva Linux at least, they're not to be explicitly used. So while rpmbuild autogenerates file requires on some interpreters, we should forbid explicit requires on files, at least for Mandriva..
For libraries we have a similar rule where we forbid explicit requires library packages..
So yes, at least a rule against explicit file dependencies. :)
Original comment by: scop
