Spec URL: http://www.linux-ati-drivers.homecall.co.uk/dpkg.spec SRPM URL: http://www.linux-ati-drivers.homecall.co.uk/dpkg-1.14.20-2.fc9.src.rpm Description: This package contains the tools (including dpkg-source) required to unpack, build and upload Debian source packages. This package also contains the programs dpkg which used to handle the installation and removal of packages on a Debian system. This package also contains dselect, an interface for managing the installation and removal of packages on the system. dependency for alien 456756 https://bugzilla.redhat.com/show_bug.cgi?id=456756 I am also seeking a sponsor.
I had build debhelper against po4a 0.34 as it wouldn't build with 0.32.
(In reply to comment #1) > I had build debhelper against po4a 0.34 as it wouldn't build with 0.32. > > Please ignore this as it is wrong .
Some remarks: * I would recommend to apply the same package split as Debian, i.e. to split this package into dpkg, dpkg-dev and dselect. This tremendously helps with regard to "Debian" compatibility and also avoids pulling-in quite an amount of deps. * I would advise you to have a look into the package's "configure --help" I comes along with several --with/--without options and environment variables you'll likely will want to apply.
(In reply to comment #3) I have split the dpkg package . http://www.linux-ati-drivers.homecall.co.uk/dpkg.spec http://www.linux-ati-drivers.homecall.co.uk/dpkg-1.14.20-4.fc9.src.rpm
GPLv2+ looks to me correct license. [rpmbuild@rocky i386]$ rp dpkg-1.14.20-4.fc9.i386.rpm dpkg.i386: E: only-non-binary-in-usr-lib 1 packages and 0 specfiles checked; 1 errors, 0 warnings. [rpmbuild@rocky i386]$ rp dpkg-dev-1.14.20-4.fc9.i386.rpm dpkg-dev.i386: E: only-non-binary-in-usr-lib 1 packages and 0 specfiles checked; 1 errors, 0 warnings. [rpmbuild@rocky i386]$ rp dselect-1.14.20-4.fc9.i386.rpm dselect.i386: E: only-non-binary-in-usr-lib 1 packages and 0 specfiles checked; 1 errors, 0 warnings. package does not own some directories 1. /etc/dpkg/ 2. /usr/lib/dpkg/ 3. /usr/lib/perl5/vendor_perl/5.10.0/Dpkg/ 4. /usr/share/dpkg/ It looks like SPEC file length can be reduced by using regular exp or some constructs which prevent similar patterns.
How do I make the package own the directory ?
e.g for /etc/dpkg/ in %files section use: %dir %{_sysconfdir}/%{name}
Thanks for the info ( I will submit updated SPEC & SRPM later ) _______________________________________________________________ Is there anything I can do for these errors ( these are the correct file locations ) dpkg.i386: E: only-non-binary-in-usr-lib dpkg-dev.i386: E: only-non-binary-in-usr-lib dselect.i386: E: only-non-binary-in-usr-lib
Snippet from output of: [rpmbuild@rocky i386]$ rpmfile dpkg-1.14.20-4.fc9.i386.rpm ----------------- /usr/lib/dpkg/mksplit 100755 perl script text executable /usr/lib/perl5/vendor_perl/5.10.0/Dpkg.pm 100644 ASCII English text /usr/lib/perl5/vendor_perl/5.10.0/Dpkg/Gettext.pm 100644 perl script text executable ----------------- It looks to me you can see Dpkg.pm is ASCII English txt. It looks it has a missing sh-bang line: #!/usr/bin/perl -w if it works inform upstream.
[rpmbuild@rocky i386]$ rp -i dpkg-1.14.20-4.fc9.i386.rpm dpkg.i386: E: only-non-binary-in-usr-lib There are only non binary files in /usr/lib so they should be in /usr/share. --- .pm files are are not intended to be run directly rather .pl files are and they don't generally don't need she-bang. So, most probably I am wrong. But you will need to investigate why that one of these files most probably mksplit has an issue.
(In reply to comment #10) > [rpmbuild@rocky i386]$ rp -i dpkg-1.14.20-4.fc9.i386.rpm > dpkg.i386: E: only-non-binary-in-usr-lib > There are only non binary files in /usr/lib so they should be in /usr/share. > > > --- > .pm files are are not intended to be run directly rather .pl files are and they > don't generally don't need she-bang. So, most probably I am wrong. > > But you will need to investigate why that one of these files most probably > mksplit has an issue. I have extracted the stable dpkg_1.13.25_i386.deb package and looked at mksplit and it appear to be the same !
(In reply to comment #11) > (In reply to comment #10) > > .pm files are are not intended to be run directly rather .pl files are and they > > don't generally don't need she-bang. These are perl-modules, which must NOT be executable nor do they need a she-bang. > > But you will need to investigate why that one of these files most probably > > mksplit has an issue. No, it doesn't have one. mksplit is a script. But there are other issues with your package: 1) It is wrong to rename install-info/cleanup-info. These are different tools than the ones in Fedora and must be installed to /usr/sbin, otherwise dpkg will not work. 2) Installing dpkg's (dpkg-)update-alternatives daemon doesn't make any sense on Fedora, because these are provided by other packages in Fedora. 3) Packaging (dpkg-)start-stop-daemon also hardly makes sense. I recommend to not building nor installing it. (%configure --without-start-stop-daemon)
(In reply to comment #12) > (In reply to comment #11) > > (In reply to comment #10) > > > > .pm files are are not intended to be run directly rather .pl files are and they > > > don't generally don't need she-bang. > These are perl-modules, which must NOT be executable nor do they need a > she-bang. > > > > But you will need to investigate why that one of these files most probably > > > mksplit has an issue. > > No, it doesn't have one. mksplit is a script. > > > But there are other issues with your package: > > 1) It is wrong to rename install-info/cleanup-info. These are different tools > than the ones in Fedora and must be installed to /usr/sbin, otherwise dpkg will > not work. > > 2) Installing dpkg's (dpkg-)update-alternatives daemon doesn't make any sense > on Fedora, because these are provided by other packages in Fedora. > > 3) Packaging (dpkg-)start-stop-daemon also hardly makes sense. I recommend to > not building nor installing it. (%configure --without-start-stop-daemon) 1) I didn't rename install-info/cleanup-info intentionally and dpkg-install-info/dpkg-cleanup-info are installed to /usr/sbin and appear to work properly. 2) should I just add "rm $RPM_BUILD_ROOT%{_sbindir}/dpkg-update-alternatives" to the SPEC file to remove it ?
(In reply to comment #13) > 1) I didn't rename install-info/cleanup-info intentionally and > dpkg-install-info/dpkg-cleanup-info are installed to /usr/sbin and appear to > work properly. They can not work properly, because a) Many *.debs have /usr/sbin/install-info hard-coded, because this is the location Debian has used ever since they exist. It does not conflict with Fedora, because Fedora rpms use a hard-coded /sbin/install-info. A dpkg-cleanup|install-info won't ever be used by any package. b) Debian's install-info is something very different than Fedora's install-info (They are incompatible). > 2) should I just add "rm $RPM_BUILD_ROOT%{_sbindir}/dpkg-update-alternatives" > to the SPEC file to remove it ? That's what I am doing in my older (dkg-1.13.25) package :)
I think that it would be better to leave dpkg-cleanup|install-info in if somebody wants to use them. As long as the name is clear and that it will only be called on purpose I think it is better to leave it in, no problem if nobody uses it, and if somebody wants to he can.
Here's the new SPEC + SRPM with the suggested changes ! http://www.linux-ati-drivers.homecall.co.uk/dpkg.spec http://www.linux-ati-drivers.homecall.co.uk/dpkg-1.14.20-5.fc9.src.rpm
(In reply to comment #15) > I think that it would be better to leave dpkg-cleanup|install-info in > if somebody wants to use them. As long as the name is clear and that > it will only be called on purpose I think it is better to leave it > in, no problem if nobody uses it, and if somebody wants to he can. I have left them in but I have renamed them to there original names as suggested !
(In reply to comment #17) > (In reply to comment #15) > > I think that it would be better to leave dpkg-cleanup|install-info in > > if somebody wants to use them. Nobody will want to use them - They are useless, because Debian doesn't have them! On the other hand /usr/sbin/cleanup-info and /usr/bin/install-info are mandatory for dpkg to work, because Debian has them. > I have left them in but I have renamed them to there original names as > suggested ! MUSTFIX: - Remove dpkg-cleanup-info, dpkg-install-info - Add /usr/sbin/cleanup-info , /use/sbin/install-info
> MUSTFIX: > > - Remove dpkg-cleanup-info, dpkg-install-info > - Add /usr/sbin/cleanup-info , /use/sbin/install-info I have already done it ! [leigh05@localhost Alien_project]$ cd dpkg-1.14.20-5.fc9.x86_64/usr/sbin/ [leigh05@localhost sbin]$ ls cleanup-info dpkg-divert dpkg-statoverride install-info [leigh05@localhost sbin]$
> > MUSTFIX: > > - Remove dpkg-cleanup-info, dpkg-install-info > - Add /usr/sbin/cleanup-info , /use/sbin/install-info Here's a link to my server ( on from 09.00GMT - 00.00GMT ) if you want to check the built RPM packages. http://leigh123.homelinux.com/dpkg/
Definition of packagename as a macro is unuseful. The description of the dpkg subpackage should be trimmed to contain only what is relevant for that sub-package. For dpkg-dev you should not use -n, but instead use dev, dpkg- will be automatically prepended. A period is missing at the end of dpkg-dev %description. Although the Group doesn't matter much, it seems to me that dpkg-dev should better be Development/Tools. There is a spurious space before the period of the dselect. I suggest using a glob for the man pages extensions, such as not to have to change the spec file when the compression scheme changes or there is no compression, like %{_mandir}/man1/dpkg-deb.1* It seems to me that %{_libdir}/dpkg/ should better be in %{_datadir} or %{_libexecdir} than in %{_libdir}. Maybe this could be reported upstream? The admindir is /var/dpkg, it should be /var/lib/dpkg, you should pass configure --with-admindir=%{_localstatedir}/lib/dpkg Also the package should certainly own %{_sysconfdir}/dpkg, and have %{_sysconfdir}/dpkg/dpkg.conf %config(noreplace). Also %{_sysconfdir}/dpkg/origin/ and /usr/share/dpkg/ are not owned. Shouldn't dpkg-dev and dselect depend on dpkg? To keep timestamps on iconved files, you can do for file in %{buildroot}%{_mandir}/*/man*/* ; do iconv -f latin1 -t utf8 $file -o $file.new touch -c -r $file $file.new mv -f $file.new $file done dpkg- prefixed executables are still there. Regarding th euse of dpkg, my investigations show that, after doing touch status mkdir updates touch available mkdir info dpkg is ready to install files, with --force-bad-path since the executables renamed/not installed are not found. This seems a bit dangerous to me. Maybe we could add an empty /etc/dpkg.conf with instdir=/var/lib/dpkg_installation to avoid clobbering the rpm managed filesystem? If we go down that way, maybe also we could ship a wrapper script that sets a PATH within /var/lib/dpkg_installation and also sets LD_LIBRARY_PATH to be able to install and run packages installed through dpkg. Maybe it shouldn't be done since it is too dangerous and debian packages pre/post scripts may harm the fedora installation? Ralf, do you use dpkg to install dpkg package on a fedora?
@leigh ping? Any updates ?
re-ping?
I haven't had time to do any work on dpkg lately , I hope to get some free time in the new year .
I think I have implemented most of the recommended changes , it hasn't been possible to use glob for the man pages extensions as doing so would pack some man pages in the wrong packages . Spec: http://www.linux-ati-drivers.homecall.co.uk/dpkg.spec SRPM: http://www.linux-ati-drivers.homecall.co.uk/dpkg-1.14.23-1.fc10.src.rpm
There are still several issues: SHOULD: - In dkg's %files, you are inconsistently using %name and dpkg. Please only use one of them. I recommend to use dpkg, only. - You are still using %packagename. Please stop it. - The latin1->utf8 transformation of the man-pages should be performed in %build. MUSTFIX: - There is a circular dependency between the dpkg and dpkg-dev, introduced by the perl modules (dpkg can not be installed without dpkg-dev). I see 3 alternatives to work around this issue: a) package the perl modules as separate package (e.g. perl-Dpkg) b) move all perl modules into dpkg c) try to sort out the details of the perl module deps. I for one would choose alternative a). b) is almost equivalent to a), while c) is likely difficult to implement, if possible at all. - Several directories are unowned, e.g. /etc/dpkg/origins /usr/lib/perl5/vendor_perl/5.10.0/Dpkg/Source /usr/lib/perl5/vendor_perl/5.10.0/Dpkg/Shlibs - Files below %{_mandir} automatically receive %doc => the %doc inside of your %lang(xx) %doc %{_mandir} ... lists are superfluous. Please remove them.
(In reply to comment #26) > MUSTFIX: > - There is a circular dependency between the dpkg and dpkg-dev, introduced by > the perl modules (dpkg can not be installed without dpkg-dev). > > I see 3 alternatives to work around this issue: I missed something: The cause of this issue is you incorrectly packaging the applications in %{_bindir}/. Correctly stuffing those applications into dpkg rsp. dpkg-dev, like debian does, automatically resolves this issue.
Spec: http://www.linux-ati-drivers.homecall.co.uk/dpkg.spec SRPM: http://www.linux-ati-drivers.homecall.co.uk/dpkg-1.14.23-3.fc10.src.rpm > - Several directories are unowned, e.g. > /etc/dpkg/origins > /usr/lib/perl5/vendor_perl/5.10.0/Dpkg/Source > /usr/lib/perl5/vendor_perl/5.10.0/Dpkg/Shlibs dpkg does own these files %dir %{_sysconfdir}/dpkg %dir %{perl_vendorlib}/Dpkg
Is there anyone doing this review? leigh, do you still need sponsorship?
(In reply to comment #29) > Is there anyone doing this review? > > leigh, do you still need sponsorship? Yes I do still need sponsorship .
IIRC, you have subsequently been sponsored. Can you put in a cvs request?
I see that you are now sponsored. Can you update this to the latest upstream version before we do a complete review? Meanwhile I found some issues that you may want to fix while you are there: ? The group that for the dev package seems wrong. This is not a library, or is it? See /usr/share/doc/rpm-*/GROUPS file for possible candidates. * There are some files in the source that refer to /usr/local/, /usr/lib/ etc. These need probably be patched, or sedded: lib/dpkg.h scripts/t/200_Dpkg_Shlibs.t scripts/t/200_Dpkg_Shlibs/ld.so.conf.d/normal.conf scripts/t/200_Dpkg_Shlibs/objdump.glib-ia64 scripts/t/200_Dpkg_Shlibs/objdump.dbd-pg scripts/Dpkg/Changelog.pm many files in man/*/* ? Can't this fix be done in %prep?: # ugly fix to get the translated man pages in utf-8 chmod 766 %{buildroot}%{_mandir}/*/man*/* for file in %{buildroot}%{_mandir}/*/man*/* ; do ... ------------- Rahul, WOW! What is the probability of having a "mid-air collision" for a bug that was idle for 3 months?
Ping. This is quite a useful package to have, Leigh are you still going to bump it to the latest upstream ?
Policy says that this should have been closed already. I'll give it a couple more days but then I'll go ahead and close it along with the alien and debhelper tickets that depend on this one.
I am willing to take over in case Leigh is no longer interested in maintaining this package as it is useful to me.
(In reply to comment #34) Can Andrew Colin Kissa continue the work ?
If this gets closed, anyone else is welcome to open their own review ticket. If that happens, please mark this one as a duplicate of the new one.
(In reply to comment #35) > I am willing to take over in case Leigh is no longer interested in maintaining > this package as it is useful to me. Free feel to take it over.
Please remove NotReady from the Whiteboard if you have sorted out who wants to submit this review and when the issues from comment:32 are resolved.
Andrew? Did you give up too? In case no one steps forward to work on this I may be able to find time to work around new year's. That's 2 months from now.
I can work on this sometime next week, i totally forgot about it.
The changes requested have been made and i have bumped to the latest upstream version. http://www.topdog-software.com/oss/SRPMS/fedora/dpkg/dpkg.spec http://www.topdog-software.com/oss/SRPMS/fedora/dpkg/dpkg-1.15.4.1-1.fc11.src.rpm
Here are my 0.02 - I added build dependencies of gcc and gcc-c++, because it won't build without them. Maybe also need to add make, I'm not sure. Also, iconv {} -o {} gives a bunch of 0 byte files -> not what is intented I think. So I took the easy way out and used recode. I was building this on CentOS 5.4, and with these changes and the removal of "lzma" (package is not available here) and "perl(extra)" from the final dependencies I was able to build and install and run 'dpkg -h' just fine. --- dpkg.spec.latest 2009-12-01 10:56:33.000000000 +0100 +++ dpkg.spec 2009-12-01 10:59:48.000000000 +0100 @@ -11,7 +11,7 @@ Patch1: fedora-fix-paths.patch BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) -BuildRequires: zlib-devel, bzip2-devel, libselinux-devel, gettext, ncurses-devel +BuildRequires: zlib-devel, bzip2-devel, libselinux-devel, gettext, ncurses-devel, gcc, gcc-c++, recode %description @@ -61,7 +61,7 @@ chmod +x %{__perl_requires} # fix to get man pages translated to utf-8 -find man -type f -exec /usr/bin/iconv -f latin1 -t utf8 {} -o {} ';' +find man -type f -exec /usr/bin/recode latin1..utf8 {} ';' %build %configure LDFLAGS='-lselinux' \ @@ -215,6 +215,10 @@ %changelog +* Tue Dec 1 2009 Stefan Seidel <bugzilla-rh> - 1.15.4.1-2 +- add required build dependencies +- fix wrong use of iconv + * Tue Nov 10 2009 Andrew Colin Kissa <andrew.net> - 1.15.4.1-1 - Upgrade to latest upstream - review changes
- The dependencies are not required. - http://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions_2 I will test the other changes on fedora and update.
(In reply to comment #43) > Also, iconv {} -o {} gives a bunch of 0 byte files -> not what is intented I > think. Correct. It's a classic beginner's mistake to redirect a program's output to its input. You need to use a temporary file. > So I took the easy way out and used recode. Please don't. Use iconv.
(In reply to comment #43) > Also, iconv {} -o {} gives a bunch of 0 byte files -> not what is intented I > think. So I took the easy way out and used recode. [tasaka1@localhost TEMP]$ echo "漢字が入った例文です" > kanji.txt [tasaka1@localhost TEMP]$ ls -al kanji.txt -rw------- 1 tasaka1 tasaka1 31 2009-12-02 00:52 kanji.txt [tasaka1@localhost TEMP]$ iconv -f UTF-8 -t EUC-JP kanji.txt -o kanji.txt [tasaka1@localhost TEMP]$ ls -la kanji.txt -rw------- 1 tasaka1 tasaka1 21 2009-12-02 00:52 kanji.txt [tasaka1@localhost TEMP]$ iconv -f EUC-JP -t UTF-8 kanji.txt -o kanji.txt [tasaka1@localhost TEMP]$ ls -al kanji.txt -rw------- 1 tasaka1 tasaka1 31 2009-12-02 00:53 kanji.txt
In rely to comment #46, #43 That's exactly what i thought, I have double checked on my fedora build machine, i do not get any 0 byte files.
Probably the effects of http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=ca668b298e9b8c2c191eae259fddfed5e03a8dd4 Someone complained at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=439720 On my Debian Etch, Lenny and CentOS 5.4 Systems with glibc versions ranging from 2.3.6 to 2.7 it gives 0 bytes, but not on Ubuntu glibc 2.10.1. Anyway, here's the glibc-independent version: +find man -type f -exec /usr/bin/iconv -f latin1 -t utf8 {} -o {}._utf8 ';' -exec mv -f {}._utf8 {} ';'
What's the state on this? Leigh does not want to package this anymore (see comment #38), so it's the choice of oget or Andrew to take it over, but please do the following: (In reply to comment #37) > If this gets closed, anyone else is welcome to open their own review ticket. > If that happens, please mark this one as a duplicate of the new one. Closing till someone else opens an own review request and closes this as duplicate.
*** This bug has been marked as a duplicate of bug 550582 ***