John Dennis wrote:
On Thu, 2007-02-08 at 19:54 -0800, Toshio Kuratomi wrote:
On Thu, 2007-02-08 at 12:30 -0500, John Dennis wrote:
1) establish a rule which says every source file must be prepended with
a unique string (i.e. the package name).
This is a de facto standard right now.
Prefixing is not universal.
If the decision is made to enforce use of $SOURCEn then rpmlint should
also validate all source files are prefixed with their package name and
enforce prefixing just like $SOURCEn would be enforced. Both represent
threats of equivalent magnitude.
However, I am yet to be convinced either rule needs to be enforced,
using build tools obviates the need for either rule. I tend to believe
the guidelines should be written with the assumption build tools will be
used. But perhaps ensuring robustness with direct use of rpmbuild also
needs to be taken into consideration even if it comes at the expense of
other positive attributes such as readability and succinctness.
My vote is fewer rules and a mandate you use sane tools.
Assuming a sane tool such as mock might be going too far the other way
though, as it eliminates the class of problems of unwanted build options.
For instance, a package foo might build against library bar by default
if it is present at build time, which won't be the case in a Fedora mock
environment unless foo specifically buildrequires bar-devel. However, if
someone was to download the SRPM and build it on their own system, it
might pick up the additional library if bar-devel is installed and build
a package that was different from the "official" one. So it's usual for
Fedora packages to explicitly disable all build options for packages
that would be "on" if a particular buildrequire is present but not used
in the Fedora package, so as to have reproducible builds. Mandating sane
tools would give people an excuse not to harden their packages in this
way, which I think would be a bad thing.
Paul.
--
Fedora-maintainers mailing list
Fedora-maintainers@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers
--
Fedora-maintainers-readonly mailing list
Fedora-maintainers-readonly@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
