Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: Eiciel (ACL editor) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179758 ------- Additional Comments From paul@xxxxxxxxxxxx 2006-02-21 11:14 EST ------- (In reply to comment #7) > # rpmlint -v eiciel-0.9-5.src.rpm > I: eiciel checking > W: eiciel strange-permission eiciel-gcc41.patch 0646 > > ok, my original file, I did chmod it when passing it between root and another > user, what is normal? 644? Yes. > I see that the template .spec file does use %{?dist} take, but I don't get .fc5 > in make RPMs is that ok for me, will it be ok in buildsys? You'll get them if you build it in mock, which includes the buildsys macros. So it'll be alright in the buildsys. > - MUST: The package must meet the Packaging Guidelines. > > hmm, should I really treat the packaging guidelines as a checklist within a > checklist? Memorise the guidelines and bear them in mind when writing specs ;-) > - MUST: The package must be licensed with an open-source compatible > license and meet other legal requirements as defined in the legal section of > Packaging Guidelines. > > Copying file is GPL2, most cpp/hpp files have explicit GPL2 in them, necessary > to check them all individually? Up to you. If the package has a README or equivalent that says what the license for the package as a whole is, that will usually do. > - MUST: The spec file for the package MUST be legible. If the reviewer is > unable to read the spec file, it will be impossible to perform a review. Fedora > Extras is not the place for entries into the Obfuscated Code Contest ([WWW] > http://www.ioccc.org/). > > I hope it's clean, I'll remove my commented section(s) following advice Comments are OK, particularly if you do something "unusual" in a spec. > - MUST: All other Build dependencies must be listed in BuildRequires. > > hmm, fedora-rmdevelrpms wanted to remove packages that would cause broken > dependencies, I guess I need to setup mock to test this? Yes. A test build in mock revealed that a buildreq of nautilus was needed. > - MUST: If the package contains shared library files located in the > dynamic linker's default paths, that package must call ldconfig in %post and > %postun. > > my .so files stay well clear of /bin and /usr/bin is that enough? The "dynamic linker's default path" are the directories listed in /etc/ld.so.conf, not /bin, /usr/bin etc. > - MUST: A package must own all directories that it creates. If it does not > create a directory that it uses, then it should require a package which does > create that directory. The exception to this are directories listed explicitly > in the Filesystem Hierarchy Standard ([WWW] > http://www.pathname.com/fhs/pub/fhs-2.3.html), as it is safe to assume that > those directories exist. > > is this talking about directories it creates at runtime, or install time, what > about my dirs e.g /usr/share/eiceil ? It's talking about either. You need to own /usr/share/eiceil for instance so that the directory will be removed if the package is removed. > - MUST: Permissions on files must be set properly. Executables should be > set with executable permissions, for example. Every %files section must include > a %defattr(...) line. > > hmmm, I din't make any change from the defattr the template gave me, presume > I've got some work to do here? I don't think so. There don't appear to be any permissions issues that I can see. > - MUST: Each package must consistently use macros, as described in the > macros section of Packaging Guidelines. > > I hope the mix of $XXX and %{xxx} that the template started with is allowed? Yes. Just don't mix variables and macros that do the same thing, e.g. $RPM_BUILD_ROOT and %{buildroot} or $RPM_OPT_FLAGS and %{optflags}. > - MUST: If a package contains library files with a suffix (e.g. > libfoo.so.1.1), then library files that end in .so (without suffix) must go in a > -devel package. > > but softlinks without suffix, pointing to the files with suffix are ok, right? I don't know if /usr/lib/nautilus/extensions-1.0/libeiciel-nautilus.so should be in a -devel package or not; I don't know enough about shared objects to say. > - MUST: Packages must not own files or directories already owned by other > packages. The rule of thumb here is that the first package to be installed > should own the files or directories that other packages may rely upon. This > means, for example, that no package in Fedora Extras should ever share ownership > with any of the files or directories owned by the filesystem or man package. If > you feel that you have a good reason to own a file or directory that another > package owns, then please present that at package review time. > > think i'm clear here I don't think so. You package currently claims everything under %{_libdir}, which includes /usr/lib/nautilus, owned by nautilus. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
