Bug 226658 - Merge Review: xsane
Merge Review: xsane
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Susi Lehtola
Fedora Package Reviews List
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-31 16:35 EST by Nobody's working on this, feel free to take it
Modified: 2009-09-25 07:22 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-25 07:22:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
susi.lehtola: fedora‑review+


Attachments (Terms of Use)
Patch against spec file in CVS (2.06 KB, patch)
2009-05-28 09:59 EDT, Susi Lehtola
no flags Details | Diff
Patch in unified mode (3.62 KB, patch)
2009-05-29 09:00 EDT, Susi Lehtola
no flags Details | Diff

  None (edit)
Description Nobody's working on this, feel free to take it 2007-01-31 16:35:27 EST
Fedora Merge Review: xsane

http://cvs.fedora.redhat.com/viewcvs/devel/xsane/
Initial Owner: nphilipp@redhat.com
Comment 1 Parag AN(पराग) 2007-02-26 06:13:06 EST
Just checked this package in Mock build environment and created patch to SPEC
--- xsane.spec  2007-02-26 16:14:55.000000000 +0530
+++ xsane-modified.spec 2007-02-26 16:15:20.000000000 +0530
@@ -1,7 +1,7 @@
 %define desktop_vendor fedora

 Name: xsane
-Summary: An X Window System front-end for the SANE scanner interface.
+Summary: An X Window System front-end for the SANE scanner interface
 Version: 0.991
 Release: 4%{?dist}
 Source0: http://www.xsane.org/download/%{name}-%{version}.tar.gz
@@ -13,7 +13,7 @@
 License: GPL
 URL: http://www.xsane.org/
 Group: Applications/Multimedia
-Buildroot: %{_tmppath}/%{name}-buildroot
+Buildroot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 BuildRequires: sane-backends-devel gimp-devel libpng-devel libjpeg-devel
 BuildRequires: desktop-file-utils >= 0.2.92
 BuildRequires: libtiff-devel
@@ -30,7 +30,7 @@
 performing the scan and then manipulating the captured image.

 %package gimp
-Summary: A GIMP plug-in which provides the SANE scanner interface.
+Summary: A GIMP plug-in which provides the SANE scanner interface
 Group: Applications/Multimedia
 Requires(post): gimp >= 2:2.2.12-4
 Requires(preun): gimp >= 2:2.2.12-4
@@ -41,7 +41,6 @@
 installed to use this package.

 %prep
-rm -rf %{buildroot}
 %setup -q
 %patch0 -p1 -b .htmlview
 %patch1 -p1 -b .medium-definitions
@@ -100,9 +99,9 @@
 %dir %{_datadir}/sane
 %dir %{_datadir}/sane/xsane
 %{_datadir}/sane/xsane/*eula*
-%{_sysconfdir}/gimp
-%{_sysconfdir}/gimp/plugins.d
-%config %{_sysconfdir}/gimp/plugins.d/xsane.conf
+%dir %{_sysconfdir}/gimp
+%dir %{_sysconfdir}/gimp/plugins.d
+%config(noreplace) %{_sysconfdir}/gimp/plugins.d/xsane.conf

 %post gimp
 if [ -x "%{_sbindir}/gimp-plugin-mgr" ]; then
@@ -372,7 +371,7 @@

 * Mon Jul 26 1999 Tim Powers <timp@redhat.com>
 - update to 0.30
-- added %defattr
+- added %%defattr
 - built for 6.1

 * Thu Apr 22 1999 Preston Brown <pbrown@redhat.com>
===========================================================================

Also you may need to add following line to SPEC for desktop-file-install
        --remove-category Application                           \
Neccesary for warning coming in build.log

Then i even saw rpmlint output is not silent on RPM. It gave me
I: xsane checking
W: xsane rpm-buildroot-usage %build %configure --with-install-root=%{buildroot}
$RPM_BUILD_ROOT should not be touched during %build or %prep stage, as it
will break short circuiting.

W: xsane rpm-buildroot-usage %build %configure --with-install-root=%{buildroot}
--disable-gimp
$RPM_BUILD_ROOT should not be touched during %build or %prep stage, as it
will break short circuiting.


Also Mock build.log is gave me following messages
acinclude.m4:8: warning: underquoted definition of AM_PATH_GTK2
acinclude.m4:8:   run info '(automake)Extending aclocal'
acinclude.m4:8:   or see
http://sources.redhat.com/automake/automake.html#Extending-aclocal
m4/gettext.m4:60: the serial number must appear before any macro definition
m4/gettext.m4:83: the serial number must appear before any macro definition

AND
sed: can't read ./intl/po2tbl.sed.in: No such file or directory


Can you please look at these things?
Comment 2 Nils Philippsen 2007-03-30 11:31:09 EDT
(In reply to comment #1)
> Just checked this package in Mock build environment and created patch to SPEC

> -Summary: An X Window System front-end for the SANE scanner interface.
> +Summary: An X Window System front-end for the SANE scanner interface

"X Window System front-end for the SANE scanner interface"

> -Buildroot: %{_tmppath}/%{name}-buildroot
> +Buildroot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

OK

>  %package gimp
> -Summary: A GIMP plug-in which provides the SANE scanner interface.
> +Summary: A GIMP plug-in which provides the SANE scanner interface

"GIMP plug-in providing the SANE scanner interface"

>  %prep
> -rm -rf %{buildroot}

OK

> -%{_sysconfdir}/gimp
> -%{_sysconfdir}/gimp/plugins.d
> -%config %{_sysconfdir}/gimp/plugins.d/xsane.conf
> +%dir %{_sysconfdir}/gimp
> +%dir %{_sysconfdir}/gimp/plugins.d
> +%config(noreplace) %{_sysconfdir}/gimp/plugins.d/xsane.conf

OK

>  * Mon Jul 26 1999 Tim Powers <timp@redhat.com>
>  - update to 0.30
> -- added %defattr
> +- added %%defattr

OK

> Also you may need to add following line to SPEC for desktop-file-install
>         --remove-category Application                           \
> Neccesary for warning coming in build.log

Please explain.

> Then i even saw rpmlint output is not silent on RPM. It gave me
> I: xsane checking
> W: xsane rpm-buildroot-usage %build %configure --with-install-root=%{buildroot}
> $RPM_BUILD_ROOT should not be touched during %build or %prep stage, as it
> will break short circuiting.
> 
> W: xsane rpm-buildroot-usage %build %configure --with-install-root=%{buildroot}
> --disable-gimp
> $RPM_BUILD_ROOT should not be touched during %build or %prep stage, as it
> will break short circuiting.

I've removed --with-install-root=... from the configure calls (let's hope it
doesn't break anything).

> Also Mock build.log is gave me following messages
> acinclude.m4:8: warning: underquoted definition of AM_PATH_GTK2
> acinclude.m4:8:   run info '(automake)Extending aclocal'
> acinclude.m4:8:   or see
> http://sources.redhat.com/automake/automake.html#Extending-aclocal
> m4/gettext.m4:60: the serial number must appear before any macro definition
> m4/gettext.m4:83: the serial number must appear before any macro definition

AFAIK that's from other pkgs' files in /usr/share/aclocal.

> 
> AND
> sed: can't read ./intl/po2tbl.sed.in: No such file or directory

I don't know about this one and why it happens.

> Can you please look at these things?

hwbrowser-0.993-2 is building with the changes above.
Comment 3 Nils Philippsen 2007-03-30 11:32:03 EDT
xsane-0.993-2 even ;-)
Comment 4 Parag AN(पराग) 2007-03-30 12:37:48 EDT
>> Also you may need to add following line to SPEC for desktop-file-install
>>         --remove-category Application                           \
>> Neccesary for warning coming in build.log

>Please explain.

When you got your package built. Kindly check build.log. There you will see now
Application word is no longer needed in .desktop files.
Comment 5 Parag AN(पराग) 2007-04-10 06:22:36 EDT
No response from maintainer
Comment 6 Nils Philippsen 2007-04-24 07:53:48 EDT
Sorry, I was a bit under water...

I'm building xsane-0.994-3.fc7 right now which doesn't list the Application
category for the desktop file anymore, please check.
Comment 7 manuel wolfshant 2009-01-10 17:01:44 EST
Parag, is there any reason left to not approve this package and get it off the list of merge reviews ?
Comment 8 Bernie Innocenti 2009-03-18 06:28:40 EDT
Is this review stuck?  I'm going to approve it in one week if nobody takes over.
Comment 9 Susi Lehtola 2009-05-28 04:20:19 EDT
(In reply to comment #8)
> Is this review stuck?  I'm going to approve it in one week if nobody takes
> over.  

No, it is not stuck, since no-one has even done the review yet!

Taking over.
Comment 10 Bernie Innocenti 2009-05-28 09:29:41 EDT
(In reply to comment #9)
> (In reply to comment #8)
> > Is this review stuck?  I'm going to approve it in one week if nobody takes
> > over.  
> 
> No, it is not stuck, since no-one has even done the review yet!

Well, Nils Philippsen did an initial review and the packager responded to it.


> Taking over.  

Sure, go on.  This review has been stuck for way too long.
Comment 11 Susi Lehtola 2009-05-28 09:34:10 EDT
- Instead of make clean'ing in between building the different versions, I'd suggest using off-root builds.

**

rpmlint output:
xsane.x86_64: W: file-not-utf8 /usr/share/doc/xsane-0.996/xsane.CHANGES
xsane.x86_64: W: file-not-utf8 /usr/share/doc/xsane-0.996/xsane.PROBLEMS
xsane.x86_64: W: file-not-utf8 /usr/share/doc/xsane-0.996/xsane.INSTALL
xsane-gimp.x86_64: W: no-documentation
4 packages and 0 specfiles checked; 0 errors, 4 warnings.

- You need to convert these to UTF-8 in the setup phase:

for doc in xsane.{CHANGES,PROBLEMS,INSTALL}; do
 iconv -f ISO-8859-1 -t utf8 $doc -o $doc.new && \
 touch -r $doc $doc.new && \
 mv $doc.new $doc
done


MUST: The package does not yet exist in Fedora. The Review Request is not a duplicate. OK
MUST: The spec file for the package is legible and macros are used consistently. ~OK
- You don't need BR: sed, it is in the standard buildroot.
- No need to define desktop_vendor as it is only used in two places and is not even supposed to be changed.

MUST: The package must be named according to the Package Naming Guidelines. OK
MUST: The spec file name must match the base package %{name}. OK
MUST: The package must be licensed with a Fedora approved license and meet the  Licensing Guidelines. OK
MUST: The License field in the package spec file must match the actual license. OK
MUST: The sources used to build the package must match the upstream source, as provided in the spec URL. OK
MUST: The package MUST successfully compile and build into binary rpms. OK
MUST: The spec file MUST handle locales properly. OK
MUST: Optflags are used and time stamps preserved. OK
MUST: Packages containing shared library files must call ldconfig. N/A

MUST: A package must own all directories that it creates or require the package that owns the directory. NEEDSWORK
- Package must not own
 %dir %{_datadir}/applications
which is a standard system directory.
- gimp package must Requires: gimp for dir ownership and not own
 %dir %{_sysconfdir}/gimp
 %dir %{_sysconfdir}/gimp/plugins.d

MUST: Files only listed once in %files listings. NEEDSWORK
- %{_datadir}/sane, %{_datadir}/sane/xsane and %{_datadir}/sane/xsane/xsane-eula.txt are owned by both xsane and xsane-gimp. Is there a good reason for this? If xsane-gimp needs those files, it'd be wiser to let xsane own them and put a Requires: %{name} = %{version}-%{release} to xsane-gimp.

MUST: Debuginfo package is complete. OK
MUST: Permissions on files must be set properly. NEEDSWORK
- Use %defattr(-,root,root,-) instead of %defattr(-,root,root).

MUST: Clean section exists. OK
MUST: Large documentation files must go in a -doc subpackage. N/A

MUST: All relevant items are included in %doc. Items in %doc do not affect runtime of application. NEEDSWORK
- Remove unneeded files from doc (rm in setup or install phase): xsane.RPM, xsane.conf, xsane.spec*, xsane.INSTALL, xsane.REMOVE

MUST: Header files must be in a -devel package. N/A
MUST: Static libraries must be in a -static package. N/A
MUST: Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig'. N/A
MUST: If a package contains library files with a suffix then library files ending in .so must go in a -devel package. N/A
MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency. N/A
MUST: Packages does not contain any .la libtool archives. N/A
MUST: Desktop files are installed properly. OK
MUST: No file conflicts with other packages and no general names. OK
MUST: Buildroot cleaned before install. OK
SHOULD: %{?dist} tag is used in release. OK
SHOULD: If the package does not include license text(s) as separate files from upstream, the packager should query upstream to include it. OK
SHOULD: The package builds in mock. OK
Comment 12 Susi Lehtola 2009-05-28 09:34:41 EDT
I'll make a patch for these issues.
Comment 13 Susi Lehtola 2009-05-28 09:59:51 EDT
Created attachment 345764 [details]
Patch against spec file in CVS
Comment 14 Susi Lehtola 2009-05-28 10:01:41 EDT
(In reply to comment #13)
> Created an attachment (id=345764) [details]
> Patch against spec file in CVS  

This should fix every issue in the review. I tried the off-root build, however it didn't work as nicely as it should. Maybe it's easier and nicer to keep the build the way it is now. I did add the SMP flags to the build, though.

Once you have committed the patch to CVS and built it in rawhide, I can check that everything is OK and approve the package.
Comment 15 Nils Philippsen 2009-05-29 08:41:24 EDT
Thanks for your effort, but I'll not use your patch because it's not very readable (better use unified diffs: diff -u) and I want to discuss some things:

(In reply to comment #11)
> - Instead of make clean'ing in between building the different versions, I'd
> suggest using off-root builds.

Later you said you had problems with that, what were these?

> **
> 
> rpmlint output:
> xsane.x86_64: W: file-not-utf8 /usr/share/doc/xsane-0.996/xsane.CHANGES
> xsane.x86_64: W: file-not-utf8 /usr/share/doc/xsane-0.996/xsane.PROBLEMS
> xsane.x86_64: W: file-not-utf8 /usr/share/doc/xsane-0.996/xsane.INSTALL
> xsane-gimp.x86_64: W: no-documentation
> 4 packages and 0 specfiles checked; 0 errors, 4 warnings.
> 
> - You need to convert these to UTF-8 in the setup phase:
> 
> for doc in xsane.{CHANGES,PROBLEMS,INSTALL}; do
>  iconv -f ISO-8859-1 -t utf8 $doc -o $doc.new && \
>  touch -r $doc $doc.new && \
>  mv $doc.new $doc
> done

applied

> - You don't need BR: sed, it is in the standard buildroot.

removed

> - No need to define desktop_vendor as it is only used in two places and is not
> even supposed to be changed.

"Existing packages that use a vendor tag must continue to do so for the life of the package." As this is a merge review, i.e. the package isn't new, I'll leave it as it is.

> MUST: A package must own all directories that it creates or require the package
> that owns the directory. NEEDSWORK
> - Package must not own
>  %dir %{_datadir}/applications
> which is a standard system directory.
> - gimp package must Requires: gimp for dir ownership and not own
>  %dir %{_sysconfdir}/gimp
>  %dir %{_sysconfdir}/gimp/plugins.d

fixed (-gimp subpackage already requires gimp)

> MUST: Files only listed once in %files listings. NEEDSWORK
> - %{_datadir}/sane, %{_datadir}/sane/xsane and
> %{_datadir}/sane/xsane/xsane-eula.txt are owned by both xsane and xsane-gimp.
> Is there a good reason for this? If xsane-gimp needs those files, it'd be wiser
> to let xsane own them and put a Requires: %{name} = %{version}-%{release} to
> xsane-gimp.

xsane and xsane-gimp can be installed independently, they both need the same xsane-eula.txt file. I believe the rule you're hinting on means files listed twice for the same package (e.g. twice in "%files gimp")

> MUST: Permissions on files must be set properly. NEEDSWORK
> - Use %defattr(-,root,root,-) instead of %defattr(-,root,root).

The latter (which I use) is functionally equivalent to the former (which isn't mandatory either).

> MUST: Clean section exists. OK
> MUST: Large documentation files must go in a -doc subpackage. N/A
> 
> MUST: All relevant items are included in %doc. Items in %doc do not affect
> runtime of application. NEEDSWORK
> - Remove unneeded files from doc (rm in setup or install phase): xsane.RPM,
> xsane.conf, xsane.spec*, xsane.INSTALL, xsane.REMOVE

I've changed the file list to only include the other documentation files.

I've commited my changes to Rawhide CVS.
Comment 16 Susi Lehtola 2009-05-29 08:59:17 EDT
(In reply to comment #15)
> Thanks for your effort, but I'll not use your patch because it's not very
> readable (better use unified diffs: diff -u) and I want to discuss some things:

Right. You could have generated an unified diff by patching a local copy of the spec file, though :)

> (In reply to comment #11)
> > - Instead of make clean'ing in between building the different versions, I'd
> > suggest using off-root builds.
> 
> Later you said you had problems with that, what were these?

The automake stuff isn't configured properly. First of all, configure reads some xsane. files (at least xsane.NEWS), so one needs to copy them to the build dir. After that things got even messier since it seemed that there were problems with header files etc as well.

This could of course be overcome rather simply: do a manual setup of the build tree by extracting the tarball twice into separate subdirs (gimp and nogimp) where the builds can be made separately.

This of course doubles the size of the -debuginfo package (although I'm not sure if debugging xsane-gimp is even possible now!).


> > - No need to define desktop_vendor as it is only used in two places and is not
> > even supposed to be changed.
> 
> "Existing packages that use a vendor tag must continue to do so for the life of
> the package." As this is a merge review, i.e. the package isn't new, I'll leave
> it as it is.

Yes, that's exactly my point. As there are only two instances where the macro is used, I'd replace them both with "fedora".

> > MUST: A package must own all directories that it creates or require the package
> > that owns the directory. NEEDSWORK
> > - Package must not own
> >  %dir %{_datadir}/applications
> > which is a standard system directory.
> > - gimp package must Requires: gimp for dir ownership and not own
> >  %dir %{_sysconfdir}/gimp
> >  %dir %{_sysconfdir}/gimp/plugins.d
> 
> fixed (-gimp subpackage already requires gimp)

Only in %post and %postun phases.

> > MUST: Files only listed once in %files listings. NEEDSWORK
> > - %{_datadir}/sane, %{_datadir}/sane/xsane and
> > %{_datadir}/sane/xsane/xsane-eula.txt are owned by both xsane and xsane-gimp.
> > Is there a good reason for this? If xsane-gimp needs those files, it'd be wiser
> > to let xsane own them and put a Requires: %{name} = %{version}-%{release} to
> > xsane-gimp.
> 
> xsane and xsane-gimp can be installed independently, they both need the same
> xsane-eula.txt file. I believe the rule you're hinting on means files listed
> twice for the same package (e.g. twice in "%files gimp")

http://fedoraproject.org/wiki/Packaging/Guidelines#DuplicateFiles

"A Fedora package must not list a file more than once in the spec file's %files listings. If you think your package is a valid exception to this, please bring it to the attention of the Packaging Committee so they can improve on this Guideline."

Now you have xsane-eula.txt and the directories listed twice. Of course, you can get around this by putting xsane-eula.txt in %doc of the xsane-gimp package.


> > MUST: Permissions on files must be set properly. NEEDSWORK
> > - Use %defattr(-,root,root,-) instead of %defattr(-,root,root).
> 
> The latter (which I use) is functionally equivalent to the former (which isn't
> mandatory either).

Hmm, the guideline at
 http://fedoraproject.org/wiki/Packaging/Guidelines#FilePermissions
states:
"Unless you have a very good reason to deviate from that, you should use %defattr(-,root,root,-) for all %files sections in your package."
Please, just use the version of the guideline.
Comment 17 Susi Lehtola 2009-05-29 09:00:52 EDT
Created attachment 345904 [details]
Patch in unified mode
Comment 18 Susi Lehtola 2009-05-29 09:02:37 EDT
The defattr line of the gimp package should be changed too in the above patch.
Comment 19 Susi Lehtola 2009-07-10 08:57:48 EDT
ping?
Comment 20 Susi Lehtola 2009-08-05 07:21:13 EDT
ping again? Nils?
Comment 21 Nils Philippsen 2009-08-05 08:47:24 EDT
Sorry for the late response.

The xsane-0.997-3.fc12 package is building right now with the changes below.

(In reply to comment #16)
> (In reply to comment #15)
> > Thanks for your effort, but I'll not use your patch because it's not very
> > readable (better use unified diffs: diff -u) and I want to discuss some things:
> 
> Right. You could have generated an unified diff by patching a local copy of the
> spec file, though :)

Yuck ;-).

> > (In reply to comment #11)
> > > - Instead of make clean'ing in between building the different versions, I'd
> > > suggest using off-root builds.
> > 
> > Later you said you had problems with that, what were these?
> 
> The automake stuff isn't configured properly. First of all, configure reads
> some xsane. files (at least xsane.NEWS), so one needs to copy them to the build
> dir. After that things got even messier since it seemed that there were
> problems with header files etc as well.
> 
> This could of course be overcome rather simply: do a manual setup of the build
> tree by extracting the tarball twice into separate subdirs (gimp and nogimp)
> where the builds can be made separately.
> 
> This of course doubles the size of the -debuginfo package (although I'm not
> sure if debugging xsane-gimp is even possible now!).

Oh, I'd rather not have that ;-). It seems we need to fix the autofoo stuff in the package to use off-root builds, but I guess this is "out of scope" for this review anyway.

> > > - No need to define desktop_vendor as it is only used in two places and is not
> > > even supposed to be changed.
> > 
> > "Existing packages that use a vendor tag must continue to do so for the life of
> > the package." As this is a merge review, i.e. the package isn't new, I'll leave
> > it as it is.
> 
> Yes, that's exactly my point. As there are only two instances where the macro
> is used, I'd replace them both with "fedora".

Now I understand you ;-). Fixed.

> > > MUST: A package must own all directories that it creates or require the package
> > > that owns the directory. NEEDSWORK
> > > - Package must not own
> > >  %dir %{_datadir}/applications
> > > which is a standard system directory.
> > > - gimp package must Requires: gimp for dir ownership and not own
> > >  %dir %{_sysconfdir}/gimp
> > >  %dir %{_sysconfdir}/gimp/plugins.d
> > 
> > fixed (-gimp subpackage already requires gimp)
> 
> Only in %post and %postun phases.

Fixed.

> > > MUST: Files only listed once in %files listings. NEEDSWORK
> > > - %{_datadir}/sane, %{_datadir}/sane/xsane and
> > > %{_datadir}/sane/xsane/xsane-eula.txt are owned by both xsane and xsane-gimp.
> > > Is there a good reason for this? If xsane-gimp needs those files, it'd be wiser
> > > to let xsane own them and put a Requires: %{name} = %{version}-%{release} to
> > > xsane-gimp.
> > 
> > xsane and xsane-gimp can be installed independently, they both need the same
> > xsane-eula.txt file. I believe the rule you're hinting on means files listed
> > twice for the same package (e.g. twice in "%files gimp")
> 
> http://fedoraproject.org/wiki/Packaging/Guidelines#DuplicateFiles
> 
> "A Fedora package must not list a file more than once in the spec file's %files
> listings. If you think your package is a valid exception to this, please bring
> it to the attention of the Packaging Committee so they can improve on this
> Guideline."
> 
> Now you have xsane-eula.txt and the directories listed twice. Of course, you
> can get around this by putting xsane-eula.txt in %doc of the xsane-gimp
> package.

No, I can't as xsane-gimp won't work properly without it in that exact location ;-). Anyway, I've moved the eula and documentation to a -common subpackage which gets pulled in by both xsane and xsane-gimp.

> > > MUST: Permissions on files must be set properly. NEEDSWORK
> > > - Use %defattr(-,root,root,-) instead of %defattr(-,root,root).
> > 
> > The latter (which I use) is functionally equivalent to the former (which isn't
> > mandatory either).
> 
> Hmm, the guideline at
>  http://fedoraproject.org/wiki/Packaging/Guidelines#FilePermissions
> states:
> "Unless you have a very good reason to deviate from that, you should use
> %defattr(-,root,root,-) for all %files sections in your package."
> Please, just use the version of the guideline.  

As I read the guideline I'm already compliant, because the one and the other mean exactly the same thing. There is no tangible benefit from substituting the short-hand version with the long-hand one other than the latter matches verbatim what's written in the guideline.
Comment 22 Susi Lehtola 2009-08-05 08:58:05 EDT
(In reply to comment #21)
> As I read the guideline I'm already compliant, because the one and the other
> mean exactly the same thing. There is no tangible benefit from substituting the
> short-hand version with the long-hand one other than the latter matches
> verbatim what's written in the guideline.  

Yeah, I discovered this only a while ago. No problem.
Comment 23 Susi Lehtola 2009-08-16 05:26:43 EDT
Well, I guess this package is fine now.

APPROVED
Comment 24 Peter Lemenkov 2009-09-25 07:22:41 EDT
I'm sure this ticket may be closed now.

Note You need to log in before you can comment on or make changes to this bug.