#12 Guidelines about how not to use $RPM_SOURCE_DIR / %{_sourcedir}
Closed: Fixed None Opened 11 years ago by spot.

https://fedoraproject.org/wiki/PackagingDrafts/RPM_Source_Dir

It was pointed out to me that some packagers are using $RPM_SOURCE_DIR/filename.foo instead of the appropriate %{SOURCE#} macro. This guideline would make this behavior officially unacceptable.


Noteworthy is that rpmlint already flags this case.

There are things you can do by referencing _sourcedir which you cannot do using the SOURCEX macros, unfortunately. (An example is pattern matching.) Certainly the common cases should be banned but I'm not sure that a complete prohibition is warranted unless there's another solution. (Perhaps it's doable in lua; I haven't had much luck with that.)

If you can quantify those valid exception cases, please go ahead and amend them to the draft.

c.f. http://www.redhat.com/archives/fedora-maintainers/2007-February/msg00232.html

Nobody ever presented any strong technical justification for banning $RPM_SOURCE_DIR back then, and there was strong resistance. What is the justification now?

The justification in the wiki draft that "the package may succeed locally and fail in the build system" is incredibly weak. So what? There are a zillion ways in which package builds may succeed locally and fail in the build system. Why does this warrant making spec files less readable?

I don't agree that the justification here is weak, or that there are a "zillion" ways in which package builds may succeed locally and fail in the build system. Please feel free to submit drafts for resolving any of those "zillion" inconsistencies.

If making your spec more readable is the reason that you find yourself in violation of this guideline, I would propose that adding hardcoded comments next to the use of %{SOURCE#} in your spec elaborating what it evaluates to accomplishes that in a safer way.

Also, worth noting is that simply because you may be skilled and attentive enough to ensure that your explicit calls never vary from the Source# defines, new packagers may not be, and they do regularly look at existing spec files to determine "best practices".

e.g. of inconsistencies: patches I forget to "$VCS add" before commit+build. A local build environment which has deps out of step vs the current Fedora. etc

a) Any packaging mistake I make which causes the package build to fail in koji can self-evidently NOT cause any detriment to the quality of Fedora packages, because it will never get shipped.

b) I and others (c.f. thread above) have stated very explicitly that we think use of $RPM_SOURCE_DIR improves readability/maintainibility of spec files.

Yet you decide to legislate against $RPM_SOURCE_DIR "for our own good" - to prevent us from making packaging mistakes which necessarily have no effect on Fedora, because they are trapped in the buildsystem later.

This is extremely patronising, not to mention decision-making by fiat. Please just remove the guideline and let maintainers use their own judgement.

I actually caught a RHEL packaging error this week which was caused by use of %{SOURCEn} rather than longhand use of $RPM_SOURCE_DIR; where

install %{SOURCEn} /some/alpha.conf

had been copied-and-pasted to

install %{SOURCEn} /some/beta.conf

and the "n" not been incremented in the latter case to pick up the correct conf file. Use of $RPM_SOURCE_DIR would have avoided that error; the mistake would have been visually obvious.

I simply do not agree with the argument that the benefit of "readability" outweighs the benefits of using the correct macros, if we are to follow that argument, we should adjust the guidelines to permit hardcoding all sorts of paths (/usr/bin, /usr/lib, /etc, and so on).

I've even pointed out how trivial it is to add comments which state what %{SOURCEn} evaluates to, and if those comments become incorrect as a result of changing the SOURCEn line, there is no effect on the package, whereas the inverse is not true.

The Packaging Committee voted unanimously to make this change, however, so to as to dispel any accusations of "decision-making by fiat", I will bring this issue up again at the next meeting.

The Fedora Packaging Committee opted to send this draft, as is, to FESCo for ratification, in accordance with our new policies involving optional ratification.

A ticket was opened with FESCo here:
https://fedorahosted.org/fesco/ticket/471

This draft was ratified by FESCo.

Merged into guidelines and announced.

If you can quantify those valid exception cases, please go ahead and amend them to
the draft.

Unfortunately, I've only seen this ticket in the announcement of the guideline already being ratified, but here's an example of IMHO reasonable use, from the kde-l10n package:
{{{
for i in $(cat %{SOURCE1000}) ; do
echo $i | grep -v '^#' && \
bzip2 -dc %{_sourcedir}/%{name}-$i-%{version}.tar.bz2 | tar -xf -
done
}}}
where Source1000: subdirs-kde-l10n is a list provided by upstream of all the languages supported, and there are ~50 SourceN: tags, which can vary from version from version, but match the languages listed in Source1000, for the tarballs provided by upstream.

Yeah, I can't think of any other way to accomplish that. We should document that exception. Reopening this ticket.

Proposed Exception text:

When upstream provides a list of supplementary source files, it is permissible to use this list in conjunction with %{sourcedir} to simplify operations on those supplementary source files.

An example of this from the kde-l10n package:

{{{
for i in $(cat %{SOURCE1000}) ; do
echo $i | grep -v '^#' && \
bzip2 -dc %{_sourcedir}/%{name}-$i-%{version}.tar.bz2 | tar -xf -
done
}}}
where Source1000: subdirs-kde-l10n is a list provided by upstream of all the languages supported, and there are ~50 SourceN: tags, which can vary from version from version, but match the languages listed in Source1000, for the tarballs provided by upstream.

Exception approved, with minor wording change (+1:5, 0:0, -1:0)
Change the wording from "When upstream provides a list" to "When there is an available list"

This one is done and about to be announced.

Metadata Update from @spot:
- Issue assigned to spot

4 years ago

Login to comment on this ticket.

Metadata