Packaging of license file in case of extracted sources
by Mattias Ellert
Hi!
I have several very similar packages being reviewed and two different
reviewers reviewing different packages have reach contradicting
conclusions about how the packaging guidelines should be interpreted.
Since it doesn't make sense that the same issue is resolved differently
depending on who happens to be the reviewer, and the reviewers have
failed to reach a common viewpoint I send this mail to this list in the
hope that there will be a way to resolve the issue consistently for all
packages.
Here is a description of the problem at hand:
When upstream distributes sources in a gigantic installer containing the
sources for 300+ packages it doesn't make sense to include this full
tarfile for each SRPM, since less than 1% of it is used to compile each
package. Instead the relevant subdirectory is extracted from this beast
(properly documented in the specfile in accordance to the packaging
guidelines).
Then the question is how should the following guideline be interpreted:
"If (and only if) the source package includes the text of the license(s)
in its own file, then that file, containing the text of the license(s)
for the package must be included in %doc."
Does this text refer to the big gigantic installer or the extracted
source tarfile in this case.
One reviewer strongly argues the first point and will only approve
packages where the license file is included, the other strongly argues
the second point and will only approve packages where the license file
is not included.
Both quote the above rule as the foundation for there standpoint. Since
it doesn't make sense to do things differently depending on who happens
to be the reviewer, I would like to have an official view of the
packaging experts on this issue.
Mattias
14 years, 11 months
How to create a subdir in %{_docdir}/%{name}-%{version}
by Christoph Wickert
Hi,
I want to create an "examples" folder inside
%{_docdir}/%{name}-%{version}. Here is my test case:
> %install
> mkdir -p $RPM_BUILD_ROOT%{_docdir}/%{name}-%{version}/examples/
> touch $RPM_BUILD_ROOT%{_docdir}/%{name}-%{version}/examples/test
>
> %files -f %{name}.lang
> %defattr(-,root,root,-)
> %doc AUTHORS COPYING ChangeLog README
> %doc %{_docdir}/%{name}-%{version}/examples/
This wont work as the first %doc line deletes and re-creates
%{_docdir}/%{name}-%{version}, so rpmbuild will fail with:
"... /usr/share/doc/foo/examples/test: cpio: Bad magic"
Any idea how I can have a subdir then?
Christoph
14 years, 11 months
Re: Packaging of license file in case of extracted sources
by Orcan Ogetbil
On 04/20/2009 06:28 AM, Mattias Ellert wrote:
> The question at hand is not whether the tarball contains inlined or
> detached licenses. The question is which tarball the guideline refers
> to. If it is the large upstream installer it does include a detached
> license file. If it is the extracted tarball it does not.
I want to make clear that the disagreement does not depend on whether
we extract source tarballs from a larger tree or not.
Let me talk over a toy example to demonstrate the situation:
Suppose I am packaging MyApp. MyApp source tree has this layout:
src/A/
src/B/
I am making MyApp-A and MyApp-B subpackages. Now there is a COPYING
file under src/A/
Should I put that COPYING file into the %doc of the MyApp-B package, if
- B requires A?
- B doesn't require A?
Let's make this clear, so that we can apply the general consensus on
the new packages.
Orcan
14 years, 11 months
Mono's dll/exe and debugpackage
by Simon Wesp
Hey all,
I have a problem with a mono package. It creates only an *.exe file and
some *.dll files in libdir. i can't create a debug package with this.
Is there a trick for this?
--
Mit freundlichen Grüßen aus dem schönen Hainzell
Simon Wesp
The G in GNU stands for GNU
http://fedoraproject.org/wiki/SimonWesp
14 years, 11 months
FW: [Bug 495529] rpmlint incorrect warning for missing-lsb-keyword Default-Stop
by Matt Domsch
Packaging Committee: either rpmlint is correct, or the guidelines are correct; but at the moment they conflict. Please see this bugzilla and review.
Thanks,
Matt
--
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux
-----Original Message-----
From: bugzilla(a)redhat.com [mailto:bugzilla@redhat.com]
Sent: Mon 4/13/2009 3:42 PM
To: Domsch, Matt
Subject: [Bug 495529] rpmlint incorrect warning for missing-lsb-keyword Default-Stop
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=495529
Ville Skyttä <ville.skytta(a)iki.fi> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |CLOSED
Resolution| |NOTABUG
--- Comment #1 from Ville Skyttä <ville.skytta(a)iki.fi> 2009-04-13 16:42:46 EDT ---
I think the documentation cited draws wrong conclusions/interpretations from
the LSB spec. One may very well want to have a service stopped by default in
some runlevels even if it is not started in any by default. The LSB specs are
quite vague too, which has resulted in rpmlint drawing its own conclusions, the
one of which in effect here is that there should be no need not to have a
Default-Stop in all init scripts, thus it always recommends adding one in all
init scripts, even if empty.
$ rpmlint -I missing-lsb-keyword
missing-lsb-keyword:
The package contains an init script that does not contain one of the LSB init
script comment block convention keywords that are recommendable for all init
scripts. If there is nothing to add to a keyword's value, include the keyword
in the script with an empty value. Note that as of version 3.2, the LSB
specification does not mandate presence of any keywords.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You reported the bug.
14 years, 11 months
wordpress guidelines -- ping?
by Ian Weller
During the most recent meeting it was decided that I would be contacted
about a few issues with the WordPress plugin packaging guidelines;
https://fedoraproject.org/wiki/User:Ianweller/WordPress_plugin_packaging_...
I wasn't contacted, but I did ask spot what the issue was, and he
reported that we needed to know if there would be a case where the
plugin may not function on either platform (mu or lack thereof). The
answer is a strong "yes" from upstream.
What are we waiting on? Is a list vote possible to get this moving
along?
--
Ian Weller <ianweller(a)gmail.com>
GnuPG fingerprint: E51E 0517 7A92 70A2 4226 B050 87ED 7C97 EFA8 4A36
14 years, 11 months
Use of %{_libdir}/gfortran
by Jussi Lehtola
Hi,
the Fortran flags in Fedora 10 read
FFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
-I/usr/lib64/gfortran/modules'
However,
# yum provides /usr/lib64/gfortran
finds no match.
What package is supposed to provide the aforementioned directory, and
what is it supposed to be used for? Should all Fortran module files be
installed in that directory?
--
Jussi Lehtola
Fedora Project Contributor
jussilehtola(a)fedoraproject.org
14 years, 11 months
How to package a patched older version of libvmime in Fedora best?
by Robert Scheck
Good evening,
I've the situation, that a package unluckily requires an older version of
libvmime and some specific/individual patches as well. The question is now,
how to package that best for Fedora and EPEL?
What I'm requiring is libvmime 0.7.1 + patches, while upstream is at 0.9.1
which is unluckily ABI and API incompatible.
There are now multiple solutions how to deal with this as I can't use 0.9.1
now and in foreseeable future:
a) Build libvmime 0.7.1 + patches in before of the software requiring it
and link statically against it. This would make sense in this case, even
if static linking is discouraged in Fedora, but nothing except that
piece of software requires actually libvmime 0.7.1 + individual patches.
b) Build libvmime 0.7.1 + patches as own package and call it e.g. something
like foobar-libvmime and rename libvmime.so.* to foobar-libvmime.so.* or
similar. That would bring me to -lfoobar-libvmime linking or something
similar, right?
Just providing a compat-libvmime seems not suitable, as compat-* in Fedora
is only providing the library, not -devel stuff which is actually needed to
build the other software requiring the old libvmime 0.7.1 + patches.
As of overlapping *.so filenames, it is not possible to avoid renaming the
patched version. Question is, which is better and which one will go through
the package review or are there better ideas how to solve this?
Yes, some far day, upstream will accept all of the individual patches and
the other software will support latest libvmime version, but this won't be
in the next time as libvmime support is somehow seemingly less interested
in being backward compatible.
Greetings,
Robert
14 years, 12 months