Re: On replacing orphaned packages
On Fri, 31 Jan 2003, Gunnar Wolf wrote: As far as I can tell, no modules depend on it - Maybe I am searching for this the wrong way, but... There's an apt-cache command which shows reverse depends... Aah, there it is, showpkg. Run that over any package, and it'll show you Reverse Depends (amongst many other useful tidbits). Now, as the packages are currently orphaned - Would the previous maintainer be the right person to address so they will ask ftpmaster to drop it? Well, since they've orphaned it, they've pretty much said I want to know no more about it. If you bring it to ftpmaster's attention, you might get something out of them. I'd give them a go first, anyway. If they're non-responsive, or aren't keen on it, post on -mentors or -devel, asking for more opinions. Someone may agree to take them on to eradicate them. But I think bugging ftpmaster (by submitting a bug against the ftp.debian.org pseudo-package) should do it, if you outline all of your reasons (like they're unmaintained, both in Debian and upstream - have a reference for that - show that there's a replacement, and that nothing in the archive depends on it). Yup... They will only break on new installs... And I think this would make Debian better, not having unmaintained packages lying around and being distributed everywhere. There are many differing opinions on that topic... g Search the archives for all of the arguments. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debconf ? for a package that doesn't work out of the box
On Sat, Feb 01, 2003 at 02:41:00AM -0500, sean finney wrote: On Fri, Jan 31, 2003 at 10:35:43PM -0800, Brian Nelson wrote: so... is there anything i can do other than putting some more documentation in /usr/share/doc? Err, README.Debian? that is what i was implying there, but was wondering if there was something *other* than that :) but with the above suggestion, i think it'll be moot, so thanks again. Some packages send reminder mail to the root during install. I do not know it is good practice or not but I think it is worth considering how they are recieved by googling previous archives. Osamu -- ~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ + Osamu Aoki [EMAIL PROTECTED] Cupertino CA USA, GPG-key: A8061F32 .''`. Debian Reference: post-installation user's guide for non-developers : :' : http://qref.sf.net and http://people.debian.org/~osamu `. `' Our Priorities are Our Users and Free Software --- Social Contract -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: libchipcard -- An api for smartcard readers (very useful forsome homebanking with gnucash-hbci)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. I'm looking for a sponsor for the following package. The addition of libchipcard to Debian would substantially increase the number of users benefitting from gnucash's hbci (home banking) extensions (cf. packages gnucash-hbci, libopenhbci, and bug number 174481), as many banks offering hbci appear to require usage of chipcards. To achieve this goal, libchipcard should be added to the official distribution, because the libopenhbci needs to be linked with libchipcard to support chipcards. * Package name: libchipcard Version : 0.7.3 Upstream Author : Martin Preuss [EMAIL PROTECTED] * URL : http://www.libchipcard.de/ * License : GPL (probably LGPL, see below) Description : An API for smartcard readers This library provides an API for accessing smartcards. Examples are memory cards, as well as HBCI (home banking), German GeldKarte (electronic small change), and KVK (health insurance) cards. Additional Information: * Preliminary Packages can be found at http://vman.de/chipcard/ or on the upstream download page. Upstream will probably release 0.7.4 this weekend, I'd like packages of this upcoming version to be included. * Present packages are do not display lintian errors, only warnings about link-to-undocumented-manpage. Man pages for all but one of those warnings have been submitted to upstream. * The COPYING file is the GPL while the source headers indicate LGPL licensing. I've notified upstream and he says that he will change the COPYING file to be LGPL and thus consistent. (There appears to have been a switch to LGPL at some point of time.) * I would possibly like to add packages for the kde tools once the KDE transition is complete. * I intend to apply for NM after getting my GPG key signed (hopefully soon), so you'd be relieved of sponsorship by 200x. Besides seeking a sponsor, I will gladly accept advice/criticism on my packaging. Thank you for reading this far. Regards Thomas -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: GnuPG key at http://www.beamnet.de/tv/ iD8DBQE+O6avriZpaaIa1PkRAvF+AKD2JYz6PT9TmcQ0UXm+KRzQFkTKewCfcSb2 lg0KXl3fQI+UjxYRkVs7oEc= =4HLD -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debconf ? for a package that doesn't work out of the box
On Sat, Feb 01, 2003 at 01:21:32AM -0800, Osamu Aoki wrote: On Sat, Feb 01, 2003 at 02:41:00AM -0500, sean finney wrote: that is what i was implying there, but was wondering if there was something *other* than that :) but with the above suggestion, i think it'll be moot, so thanks again. Some packages send reminder mail to the root during install. That's usually due to debconf. Keep debconf notes to a minimum, please. -- Colin Watson [[EMAIL PROTECTED]] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
unITPing
Hello, I ITP'ed FXRuby (libfox-ruby) some time ago. But in the meantime I've been cought up in another project (typical ;) and also found unofficial libfox-ruby packages[0] (for the unstable ruby interpreter). So I have kind of lost interest in packaging it and want to RFP it instead as I still like to see it become part of debian. Should I just file an RFP bug somehow or what should I do ? [0] http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/60179 -- Jonas Fonseca -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unITPing
On Sat, Feb 01, 2003 at 01:22:30PM +0100, Jonas Fonseca wrote: Should I just file an RFP bug somehow or what should I do ? Don't file a new one, retitle the old one to RFP. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unITPing
Hi Jonas! You wrote: Should I just file an RFP bug somehow or what should I do ? Just retitle the existing bug to an RFP. -- Kind regards, ++ | Bas Zoetekouw | GPG key: 0644fab7 | || Fingerprint: c1f5 f24c d514 3fec 8bf6 | | [EMAIL PROTECTED], [EMAIL PROTECTED] | a2b1 2bae e41f 0644 fab7 | ++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Packagin mozilla plugin
Hi all I'm trying to package a mozilla plugin (enigmail), but i have a problem with build dependences because I need a precompiled mozilla tree. I have several options. Option a) I omit the tar.gz sources and I use a xpi compiled by my own The deb installs this xpi like the mozilla-locale packages Option b) I include the mozilla source tree and the tar.gz I dont like this option because teh size and the compiling time grows very very much. Option c) Create a mozilla-dev? package and use this one like build dependence Well, i have a preliminary package using the option a but i'm not sure this is the right option Best regards Celso González [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packagin mozilla plugin
Celso, Option c) Create a mozilla-dev? package and use this one like build dependence Guess what? There is already a mozilla-dev package. :-) Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 msg08482/pgp0.pgp Description: PGP signature
Re: dh_perl
Colin Watson [EMAIL PROTECTED] writes: On Fri, Jan 31, 2003 at 10:15:31PM +, Roger Leigh wrote: I'm using dh_perl to calculate the package dependencies for a perl script in the cupsys-driver-gimpprint package. I thought this was working, but it's not getting the dependencies right. dh_perl doesn't (currently) attempt to calculate general module dependencies, only core dependencies. OK, thanks. I guess that, due to the nature of the perl parser, adding this functionality would be non-trivial? Or would finding all instances of use, require and use lib be sufficient? Even this looks like it could get complex, rather fast, since you can use variables (potentially) in other modules) as arguments, but I'm not a Perl guru. -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848 available on public keyservers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dh_perl
On Sat, Feb 01, 2003 at 12:57:31PM +, Roger Leigh wrote: Colin Watson [EMAIL PROTECTED] writes: dh_perl doesn't (currently) attempt to calculate general module dependencies, only core dependencies. OK, thanks. I guess that, due to the nature of the perl parser, adding this functionality would be non-trivial? Or would finding all instances of use, require and use lib be sufficient? I would use the various introspection-related modules to do this (maybe Devel::Symdump or B?), but it's not possible to get it reliably correct automatically. I think there are plenty of not-particularly-pathological scripts and modules in the distribution that would easily stretch the limits of any tool trying to calculate Perl module dependencies. As such, I'd rather not see something like this in dh_perl, whose output is expected to be used unmodified. It should be in some other tool which maintainers can run and then edit the results as appropriate. -- Colin Watson [[EMAIL PROTECTED]] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dh_perl
On Sat, Feb 01, 2003 at 05:00:19PM -0500, Joey Hess wrote: The module package may not even be installed, the module may be used conditionally, a versioned dependency may be needed, multiple packages may provide the same module (and a dependency on a virtual package or an ored dependency needed), and so on. Ahh OK versioning I'd not considered, nor virtual packages - but I think it's fair to assume the required package(s) must be installed, otherwise the packager wouldn't be trying to automatically determine the dependancies in the first place. Thanks for the other suggestions though. Steve --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: question about conffiles and prerm/postrm
On Sat, Feb 01, 2003 at 01:39:43PM -0500, sean finney wrote: i'm working on a package that has a directory in /etc/sugarplum and in this directory two conffiles and one other (empty) directory. when i purge the package, i get: balthasar[/home/seanius/sugarplum]13:17:02# dpkg --purge sugarplum (Reading database ... 69541 files and directories currently installed.) Removing sugarplum ... dpkg - warning: while removing sugarplum, directory `/etc/sugarplum' not empty so not removed. Purging configuration files for sugarplum ... See bug #59343 and those merged with it. and if i don't do anything about it, afterwards the /etc/sugarplum directory remains. what's the best way to not leave cruft behind like that? right now i have a little snippet of code that checks for an empty sugarplum directory in a postrm purge, which works, but i'm not sure it's how it ought to be done. This is the best that you can do right now. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debconf ? for a package that doesn't work out of the box
On Fri, Jan 31, 2003 at 10:35:43PM -0800, Brian Nelson wrote: i'm throwing together a cgi script package that requires certain lines be added to the apache configuration file on the webserver in order to work, so there's no way it can work out of the box as far as i can figure, at least until apache gets some kind of conf.d ability. Check out the wwwconfig-common package. Does that help? yeah, i think should do the trick, thanks! so... is there anything i can do other than putting some more documentation in /usr/share/doc? Err, README.Debian? that is what i was implying there, but was wondering if there was something *other* than that :) but with the above suggestion, i think it'll be moot, so thanks again. thanks, sean pgp4qRLNqg2gZ.pgp Description: PGP signature
Re: On replacing orphaned packages
On Fri, 31 Jan 2003, Gunnar Wolf wrote: As far as I can tell, no modules depend on it - Maybe I am searching for this the wrong way, but... There's an apt-cache command which shows reverse depends... Aah, there it is, showpkg. Run that over any package, and it'll show you Reverse Depends (amongst many other useful tidbits). Now, as the packages are currently orphaned - Would the previous maintainer be the right person to address so they will ask ftpmaster to drop it? Well, since they've orphaned it, they've pretty much said I want to know no more about it. If you bring it to ftpmaster's attention, you might get something out of them. I'd give them a go first, anyway. If they're non-responsive, or aren't keen on it, post on -mentors or -devel, asking for more opinions. Someone may agree to take them on to eradicate them. But I think bugging ftpmaster (by submitting a bug against the ftp.debian.org pseudo-package) should do it, if you outline all of your reasons (like they're unmaintained, both in Debian and upstream - have a reference for that - show that there's a replacement, and that nothing in the archive depends on it). Yup... They will only break on new installs... And I think this would make Debian better, not having unmaintained packages lying around and being distributed everywhere. There are many differing opinions on that topic... g Search the archives for all of the arguments. - Matt
Re: Producing a None-Hardware specific .deb
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Ian. Ian Wilkinson wrote: I am currently the developer of a cgi application (BlueLava, if anyone's interested :-)). I've read as much as I can find about making .debs but I can find nothing about producing a none-architecture specific .deb. Probably that's because it's not difficult (different from arch-specific) enough to have a huge amount of documentation on this topic. I think that the comments in http://www.debian.org/doc/debian-policy/ap-pkg-controlfields.html#s-pkg-f-Architecture. as well as the section on debian/rules at http://www.debian.org/doc/debian-policy/ap-pkg-sourcepkg.html#s-pkg-debianrules (look for binary-indep) are pretty much all you need. Note that there also is a perl-policy http://www.debian.org/doc/packaging-manuals/perl-policy/ you might want to consult. Cheers Thomas -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: GnuPG key at http://www.beamnet.de/tv/ iD8DBQE+O4bwriZpaaIa1PkRAuiAAJ9J/7h8oRrmZB2bxJtD5YFG4uwSjgCZAbOA ab5ofjJN1FOj7ybZwcaXpUo= =PPYo -END PGP SIGNATURE-
RFS: libchipcard -- An api for smartcard readers (very useful for some homebanking with gnucash-hbci)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. I'm looking for a sponsor for the following package. The addition of libchipcard to Debian would substantially increase the number of users benefitting from gnucash's hbci (home banking) extensions (cf. packages gnucash-hbci, libopenhbci, and bug number 174481), as many banks offering hbci appear to require usage of chipcards. To achieve this goal, libchipcard should be added to the official distribution, because the libopenhbci needs to be linked with libchipcard to support chipcards. * Package name: libchipcard Version : 0.7.3 Upstream Author : Martin Preuss [EMAIL PROTECTED] * URL : http://www.libchipcard.de/ * License : GPL (probably LGPL, see below) Description : An API for smartcard readers This library provides an API for accessing smartcards. Examples are memory cards, as well as HBCI (home banking), German GeldKarte (electronic small change), and KVK (health insurance) cards. Additional Information: * Preliminary Packages can be found at http://vman.de/chipcard/ or on the upstream download page. Upstream will probably release 0.7.4 this weekend, I'd like packages of this upcoming version to be included. * Present packages are do not display lintian errors, only warnings about link-to-undocumented-manpage. Man pages for all but one of those warnings have been submitted to upstream. * The COPYING file is the GPL while the source headers indicate LGPL licensing. I've notified upstream and he says that he will change the COPYING file to be LGPL and thus consistent. (There appears to have been a switch to LGPL at some point of time.) * I would possibly like to add packages for the kde tools once the KDE transition is complete. * I intend to apply for NM after getting my GPG key signed (hopefully soon), so you'd be relieved of sponsorship by 200x. Besides seeking a sponsor, I will gladly accept advice/criticism on my packaging. Thank you for reading this far. Regards Thomas -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: GnuPG key at http://www.beamnet.de/tv/ iD8DBQE+O6avriZpaaIa1PkRAvF+AKD2JYz6PT9TmcQ0UXm+KRzQFkTKewCfcSb2 lg0KXl3fQI+UjxYRkVs7oEc= =4HLD -END PGP SIGNATURE-
Re: debconf ? for a package that doesn't work out of the box
On Sat, Feb 01, 2003 at 01:21:32AM -0800, Osamu Aoki wrote: On Sat, Feb 01, 2003 at 02:41:00AM -0500, sean finney wrote: that is what i was implying there, but was wondering if there was something *other* than that :) but with the above suggestion, i think it'll be moot, so thanks again. Some packages send reminder mail to the root during install. That's usually due to debconf. Keep debconf notes to a minimum, please. -- Colin Watson [EMAIL PROTECTED]
unITPing
Hello, I ITP'ed FXRuby (libfox-ruby) some time ago. But in the meantime I've been cought up in another project (typical ;) and also found unofficial libfox-ruby packages[0] (for the unstable ruby interpreter). So I have kind of lost interest in packaging it and want to RFP it instead as I still like to see it become part of debian. Should I just file an RFP bug somehow or what should I do ? [0] http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/60179 -- Jonas Fonseca
Re: unITPing
On Sat, Feb 01, 2003 at 01:22:30PM +0100, Jonas Fonseca wrote: Should I just file an RFP bug somehow or what should I do ? Don't file a new one, retitle the old one to RFP. Michael
Re: unITPing
Hi Jonas! You wrote: Should I just file an RFP bug somehow or what should I do ? Just retitle the existing bug to an RFP. -- Kind regards, ++ | Bas Zoetekouw | GPG key: 0644fab7 | || Fingerprint: c1f5 f24c d514 3fec 8bf6 | | [EMAIL PROTECTED], [EMAIL PROTECTED] | a2b1 2bae e41f 0644 fab7 | ++
Packagin mozilla plugin
Hi all I'm trying to package a mozilla plugin (enigmail), but i have a problem with build dependences because I need a precompiled mozilla tree. I have several options. Option a) I omit the tar.gz sources and I use a xpi compiled by my own The deb installs this xpi like the mozilla-locale packages Option b) I include the mozilla source tree and the tar.gz I dont like this option because teh size and the compiling time grows very very much. Option c) Create a mozilla-dev? package and use this one like build dependence Well, i have a preliminary package using the option a but i'm not sure this is the right option Best regards Celso González [EMAIL PROTECTED]
Re: How to be a great Debian Developer (was Re: Question about seeking (finding) a sponsor)
Hi Chad On Sonntag, 26. Januar 2003 23:55, Chad Miller wrote: This is something you should do if and when you're pretty sure that you don't want your work to be just exercise. There's nothing wrong with packaging something just for the experience, note; you don't have to be a package maintainer to be a developer. Something you shold know: In germany (yes, again) many debian-users are waiting for exactly this one libchipcard package, and within last three or four weeks many postings in debian-user-german were related to openhbci/gnucash/ libchipcard/aqmoney. _Many_ debian-users will get _much benefit from Thomas' work. Its a quite sexy package, indeed. -- Gruß Frank
Re: Packagin mozilla plugin
Celso, Option c) Create a mozilla-dev? package and use this one like build dependence Guess what? There is already a mozilla-dev package. :-) Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 pgpBEej03Ntyk.pgp Description: PGP signature
Re: dh_perl
Colin Watson [EMAIL PROTECTED] writes: On Fri, Jan 31, 2003 at 10:15:31PM +, Roger Leigh wrote: I'm using dh_perl to calculate the package dependencies for a perl script in the cupsys-driver-gimpprint package. I thought this was working, but it's not getting the dependencies right. dh_perl doesn't (currently) attempt to calculate general module dependencies, only core dependencies. OK, thanks. I guess that, due to the nature of the perl parser, adding this functionality would be non-trivial? Or would finding all instances of use, require and use lib be sufficient? Even this looks like it could get complex, rather fast, since you can use variables (potentially) in other modules) as arguments, but I'm not a Perl guru. -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848 available on public keyservers
Re: dh_perl
On Sat, Feb 01, 2003 at 12:57:31PM +, Roger Leigh wrote: Colin Watson [EMAIL PROTECTED] writes: dh_perl doesn't (currently) attempt to calculate general module dependencies, only core dependencies. OK, thanks. I guess that, due to the nature of the perl parser, adding this functionality would be non-trivial? Or would finding all instances of use, require and use lib be sufficient? I would use the various introspection-related modules to do this (maybe Devel::Symdump or B?), but it's not possible to get it reliably correct automatically. I think there are plenty of not-particularly-pathological scripts and modules in the distribution that would easily stretch the limits of any tool trying to calculate Perl module dependencies. As such, I'd rather not see something like this in dh_perl, whose output is expected to be used unmodified. It should be in some other tool which maintainers can run and then edit the results as appropriate. -- Colin Watson [EMAIL PROTECTED]
Re: Packagin mozilla plugin
On Sat, Feb 01, 2003 at 02:25:46PM +0100, Simon Richter wrote: Celso, Option c) Create a mozilla-dev? package and use this one like build dependence Guess what? There is already a mozilla-dev package. :-) Ups :-) Great but terrible, now I have to fight with a long Makefile I hope in a few days i'll be back looking for a sponsor Best Regards Celso González [EMAIL PROTECTED]
question about conffiles and prerm/postrm
hey mentors i'm working on a package that has a directory in /etc/sugarplum and in this directory two conffiles and one other (empty) directory. when i purge the package, i get: balthasar[/home/seanius/sugarplum]13:17:02# dpkg --purge sugarplum (Reading database ... 69541 files and directories currently installed.) Removing sugarplum ... dpkg - warning: while removing sugarplum, directory `/etc/sugarplum' not empty so not removed. Purging configuration files for sugarplum ... and if i don't do anything about it, afterwards the /etc/sugarplum directory remains. what's the best way to not leave cruft behind like that? right now i have a little snippet of code that checks for an empty sugarplum directory in a postrm purge, which works, but i'm not sure it's how it ought to be done. thanks, sean pgpIEJUlJMb5v.pgp Description: PGP signature
Re: dh_perl
Colin Watson wrote: I would use the various introspection-related modules to do this (maybe Devel::Symdump or B?), but it's not possible to get it reliably correct automatically. I think there are plenty of not-particularly-pathological scripts and modules in the distribution that would easily stretch the limits of any tool trying to calculate Perl module dependencies. As such, I'd rather not see something like this in dh_perl, whose output is expected to be used unmodified. It should be in some other tool which maintainers can run and then edit the results as appropriate. Yes, it's very hard to get right and even if you do, mostly, there is still the issue of mapping perl modules into debian packages, which would be hard for debhelper to do, as it would have to depend on having an up-to-date package database available. And to really do this right you probably need a layer of indirection with room for maintainer overrides as the shlibs files provide for automated shared library dependency calculation. -- see shy jo pgpLkEHdfTTVh.pgp Description: PGP signature
Re: dh_perl
On Sat, Feb 01, 2003 at 01:55:53PM -0500, Joey Hess wrote: Yes, it's very hard to get right and even if you do, mostly, there is still the issue of mapping perl modules into debian packages, which would be hard for debhelper to do, as it would have to depend on having Mapping from a perl module to a Debian package should be trivial, I would have thought. Given the system upon which dh_perl would be run would have the modules installed it should be a simple matter of running 'dpkg --search path/to/perl/module.pm' - or am I missing something obvious? I agree that the functionality should be moved to a seperate tool though. Steve --- www.steve.org.uk
Re: dh_perl
Steve Kemp wrote: Mapping from a perl module to a Debian package should be trivial, I would have thought. Given the system upon which dh_perl would be run would have the modules installed it should be a simple matter of running 'dpkg --search path/to/perl/module.pm' - or am I missing something obvious? The module package may not even be installed, the module may be used conditionally, a versioned dependency may be needed, multiple packages may provide the same module (and a dependency on a virtual package or an ored dependency needed), and so on. -- see shy jo pgpbOHabTDUVV.pgp Description: PGP signature
Re: dh_perl
On Sat, Feb 01, 2003 at 05:00:19PM -0500, Joey Hess wrote: The module package may not even be installed, the module may be used conditionally, a versioned dependency may be needed, multiple packages may provide the same module (and a dependency on a virtual package or an ored dependency needed), and so on. Ahh OK versioning I'd not considered, nor virtual packages - but I think it's fair to assume the required package(s) must be installed, otherwise the packager wouldn't be trying to automatically determine the dependancies in the first place. Thanks for the other suggestions though. Steve ---
Re: question about conffiles and prerm/postrm
On Sat, Feb 01, 2003 at 01:39:43PM -0500, sean finney wrote: i'm working on a package that has a directory in /etc/sugarplum and in this directory two conffiles and one other (empty) directory. when i purge the package, i get: balthasar[/home/seanius/sugarplum]13:17:02# dpkg --purge sugarplum (Reading database ... 69541 files and directories currently installed.) Removing sugarplum ... dpkg - warning: while removing sugarplum, directory `/etc/sugarplum' not empty so not removed. Purging configuration files for sugarplum ... See bug #59343 and those merged with it. and if i don't do anything about it, afterwards the /etc/sugarplum directory remains. what's the best way to not leave cruft behind like that? right now i have a little snippet of code that checks for an empty sugarplum directory in a postrm purge, which works, but i'm not sure it's how it ought to be done. This is the best that you can do right now. -- - mdz
Re: debconf ? for a package that doesn't work out of the box
sean finney [EMAIL PROTECTED] writes: hey -mentors i'm throwing together a cgi script package that requires certain lines be added to the apache configuration file on the webserver in order to work, so there's no way it can work out of the box as far as i can figure, at least until apache gets some kind of conf.d ability. Check out the wwwconfig-common package. Does that help? so... is there anything i can do other than putting some more documentation in /usr/share/doc? Err, README.Debian? the one idea that comes to my mind is displaying a single-screen debconf message saying how to get it to work. how kosher is that, and if kosher, at what priority should such a message be set? I think debconf notes are frowned upon in general, so I would try to avoid using them. -- My secret to happiness... is that I have a heart of a 12-year-old boy. It's over here in a jar. Would you like to see it? pgp3sCJw8S4e3.pgp Description: PGP signature
