On Fri, Dec 07, 2001 at 05:19:36AM +0100, Manfred Wassmann wrote:
>
> I have uploaded my current Debian packages to
> http://www.b.shuttle.de/ncc-1701/foomatic/
Excellent! I have had a look, and things look mostly good so far. I
particularly applaud you on your choice of versioning; it should allow
you to adjust to any changes Grant decides to make to the versioning
without resorting to epochs.
Lintian reports the following on your packages:
W: foomatic source: out-of-date-standards-version 3.1.1
E: foomatic-bin: perl-module-in-core-directory usr/share/perl/5.6.0/
E: foomatic-bin: perl-module-in-core-directory usr/share/perl/5.6.0/Foomatic/
E: foomatic-bin: perl-module-in-core-directory
usr/share/perl/5.6.0/Foomatic/DB.pm
E: foomatic-bin: perl-module-in-core-directory
usr/share/perl/5.6.0/Foomatic/PPD.pm
E: foomatic-bin: perl-module-in-core-directory
usr/share/perl/5.6.0/Foomatic/UIElem.pm
E: foomatic-bin: perl-module-in-core-directory
usr/share/perl/5.6.0/Foomatic/GrovePath.pm
E: foomatic-bin: perl-module-in-core-directory
usr/share/perl/5.6.0/Foomatic/Defaults.pm
The Standards-Version thing isn't a big deal, but the location of the
modules is. By my reading of the Perl policy, those should be
installed to /usr/share/perl5 instead of /usr/share/perl/5.6.0.
Also, your descriptions in debian/control weren't formatted right.
They should be:
Description: <short one-line summary>
<first line of longer summary>
...
<last line of longer summary>
There are a few other minor things. The CUPS package in Debian is
called "cupsys", not "cups". You should also include PDQ (package
"pdq") as a possible print spooler that foomatic can use. When
depending on a virtual package, it's always good to or-depend on a
real package that Provides the virtual package and should always
exist; apt sometimes gets into tizzies if this isn't done.
I've made a patch, which is attached to this message. This patch
should fix all of the problems I mentioned here. I'll let you apply
it, look it over, and build new packages to your liking for me to
upload. Note that I've done version numbering NMU-style; you can
remove the NMU entry if you like and do whatever you think best for
the versioning and changelog entries.
I'd also recommend that you implement a real "debian/rules build"
target, instead of just building in the install step. You shouldn't
need separate build-indep and build-arch targets; just a "build"
target should suffice. The patch doesn't do this, though.
> Please have a look at debian/TODO, there are some issues I wasn't sure
> about.
Build-Depends are in my patch. They appear to jive with the Debian
Perl policy. I imagine the porters will be letting you know if the
build deps aren't up to snuff; check buildd.debian.org once the
packages are accepted into unstable.
The switch to dh_installman is also there.
I haven't done anything about handling external data file packages,
but I don't think it should be difficult. The foomatic-bin package
could provide a "register-foomatic-db" or some such that packages
providing foomatic data are required to run in their postinst.
> I have also checked the debian related files into the foomatic cvs
> repository.
>
> >
> > In that case, all of this might be moot. But oh well. (Manfred, if
> > you're interested in any of this, let me know and I'll tell you how to
> > do it.)
>
> I'd appreciate that. Your proposal for the changelog problem sounds very
> reasonable.
OK, here's what I was thinking:
Upstream would be responsible for maintaining two changelog entries
that would look something like this:
foomatic (0.20011206-0.2) unstable; urgency=low
* CVS changes since the nightly pull.
-- Grant Taylor <[EMAIL PROTECTED]> Tue, 06 Dec 2001 00:00:15 +0100
foomatic (0.20011206-0.1) unstable; urgency=low
* Upstream CVS nightly pull.
-- Grant Taylor <[EMAIL PROTECTED]> Tue, 06 Dec 2001 00:00:00 +0100
Most of the information could be changed to something else; the
important parts are the change date (after the maintainer name and
E-mail), the package name, and the version.
When pulling from CVS, the first (-0.1) changelog entry would be
changed to reflect the new date, and the second would be removed.
Then, the daily tarball would be made and stuck wherever it needed to
be stuck. Then, a modified second changelog entry would be attached
with the proper dates, and debian/changelog would then be checked into
CVS. This could all be done with a script, and could be part of
whatever script creates the daily tarballs now.
When you would do a new Debian upload, you would remove these two
changelog entries and add your own (with normal Debian version
numbering). You would check in your Debian changelog along with all
your other changes; the script would have to be smart enough to
recognize this and add its changelog entries in the right places.
This would allow people to build Debian packages based off the nightly
tarballs or current CVS; Grant or Till could even autobuild such
packages every evening and offer them through their own apt
repository. Any checkout from current CVS would be considered newer
than nightlies. An "official" package would always trump CVS or
nightly packages, on the theory that a package that was attended to by
a Debian maintainer is always superior for Debian systems. But, in
all cases, a newer package would trump an older one, so an official
package from 2001-12-06's source could be upgraded from a local
package built from 2001-12-08's source, which would then be upgraded
to the official package again when you upload the one based on
2001-12-09's source.
Obviously, this would require cooperation from Grant and Till. If
they need any help implementing any of my crazy idea, I don't mind
pitching in.
diff --recursive --unified --new-file foomatic-0.20011206-old/debian/changelog
foomatic-0.20011206/debian/changelog
--- foomatic-0.20011206-old/debian/changelog Thu Dec 6 19:17:17 2001
+++ foomatic-0.20011206/debian/changelog Sun Dec 9 18:24:47 2001
@@ -1,3 +1,15 @@
+foomatic (0.20011206-1.1) unstable; urgency=low
+
+ * NMU.
+ * Added proper Build-Depends.
+ * Updated Standards-Version.
+ * Fixed the descriptions to be formatted properly.
+ * Fixed the Perl libraries to be installed to the proper location.
+ * That Recommendation should be "cupsys", not "cups".
+ * Added pdq to the list of print spoolers in Recommends.
+
+ -- Jeff Licquia <[EMAIL PROTECTED]> Sun, 9 Dec 2001 18:22:49 -0500
+
foomatic (0.20011206-1) unstable; urgency=low
* Initial Release
diff --recursive --unified --new-file foomatic-0.20011206-old/debian/control
foomatic-0.20011206/debian/control
--- foomatic-0.20011206-old/debian/control Thu Dec 6 19:16:17 2001
+++ foomatic-0.20011206/debian/control Sun Dec 9 21:10:01 2001
@@ -2,15 +2,16 @@
Section: text
Priority: optional
Maintainer: Manfred Wassmann <[EMAIL PROTECTED]>
-Standards-Version: 3.1.1
-Build-Depends: debhelper
+Standards-Version: 3.5.6
+Build-Depends: debhelper (>= 3.0.18), perl (>= 5.6.0-16)
Package: foomatic-bin
Architecture: any
Depends: ${perl:Depends}, libstorable-perl, libxml-grove-perl, libxml-twig-perl
-Recommends: gs | gs-aladdin, cups | lpr | lprng, foomatic-data
-Description: Printer/Driver-Database, PPD generator and filter backends for
- various Printing systems from cups over lp* to pdq.
+Recommends: gs | gs-aladdin, cupsys | lpr | lprng | pdq, foomatic-db |
foomatic-data
+Description: Printer/Driver database and print system - binaries
+ Foomatic is a printer and driver database with PPD generator and filter
+ backends for various Printing systems from cups over lp* to pdq.
.
These are the architecture dependent files, i.e. the filter scripts
and perl libraries.
@@ -19,8 +20,9 @@
Architecture: all
Provides: foomatic-data
Depends: libstorable-perl, libxml-grove-perl, libxml-twig-perl, foomatic-bin
-Description: Printer/Driver-Database, PPD generator and filter backends for
- various Printing systems from cups over lp* to pdq.
+Description: Printer/Driver database and print system - main database
+ Foomatic is a printer and driver database with PPD generator and filter
+ backends for various Printing systems from cups over lp* to pdq.
.
This package contains the database.
diff --recursive --unified --new-file
foomatic-0.20011206-old/debian/foomatic-bin.manpages
foomatic-0.20011206/debian/foomatic-bin.manpages
--- foomatic-0.20011206-old/debian/foomatic-bin.manpages Wed Dec 31
19:00:00 1969
+++ foomatic-0.20011206/debian/foomatic-bin.manpages Sun Dec 9 20:36:57 2001
@@ -0,0 +1,12 @@
+foomatic-addpjloptions.8
+foomatic-combo-xml.1
+foomatic-compiledb.8
+foomatic-configure.1
+foomatic-datafile.8
+foomatic-getpjloptions.8
+foomatic-gswrapper.1
+foomatic-kitload.8
+foomatic-ppdload.8
+foomatic-preferred-driver.8
+foomatic-printjob.1
+lpdomatic.8
diff --recursive --unified --new-file foomatic-0.20011206-old/debian/rules
foomatic-0.20011206/debian/rules
--- foomatic-0.20011206-old/debian/rules Thu Dec 6 19:18:44 2001
+++ foomatic-0.20011206/debian/rules Sun Dec 9 20:37:17 2001
@@ -9,7 +9,7 @@
INDEP_INSTALLPREFIX=$(CURDIR)/debian/foomatic-db
export INSTALLPREFIX
-MAKEFLAGS:=$(MAKEFLAGS) PREFIX=$(PREFIX) PERL_INSTALLDIRS=perl
+MAKEFLAGS:=$(MAKEFLAGS) PREFIX=$(PREFIX) PERL_INSTALLDIRS=vendor
all: binary
@@ -28,7 +28,7 @@
dh_installdirs -a
$(MAKE) -ef Makefile build install-bin
# FIXME: Why doesn't this get installed through lib/Makefile
- cp -pv lib/Foomatic/Defaults.pm
$(INSTALLPREFIX)/usr/share/perl/5.6.0/Foomatic
+ cp -pv lib/Foomatic/Defaults.pm
$(INSTALLPREFIX)/usr/share/perl5/Foomatic
install: install-indep install-arch
@@ -90,7 +90,7 @@
dh_installchangelogs
dh_installmenu
dh_installcron
- dh_installmanpages -pfoomatic-bin
+ dh_installman
dh_movefiles
dh_strip
dh_compress
