Re: Alpha machine
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17-Apr-2001 Davide Puricelli wrote: > On Tue, Apr 17, 2001 at 01:09:14PM +0200, Michael Weber wrote: >> On Tue, Apr 17, 2001 at 13:03:44 +0200, Russell Coker wrote: >> > What is the name of the Alpha machine for Debian package development? >> >> faure.d.o > > and lully. Whose last update from the LDAP database was in March 4, according to Joy :-( - -- carlos laviola - icq #55799523 $ chown us:us /your_base -R chown: what you say!! -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE63O2ZZAYCJzUW03IRAl8VAJ9GhIRXSs7sP8aw+oIdFcYIZwyicwCdH6Di ySOz76K6FiPlWpIfY5NgJVg= =gTXB -END PGP SIGNATURE-
Re: Basic lintian errors.
Gavin Hamill writes: > I'm using debhelper, and there's dh_installman listed in debian/rules, but > not dh_installmanpages... 'man dh_installman' is your friend[1]. you need to create a file debian/.manpages and list the manpages to be installed in there. For example: ; pwd /home/decklin/debian/muddleftpd-1.3.9 ; cat debian/muddleftpd.manpages debian/mudpasswd.1 ; You can also use the list-all-manpages-on-the-command-line approach, but I prefer this way. [1] in fact, reading *all* the debhelper documentation before creating dh packages is a good idea, so that you understand what the various tools are doing for you behind the scenes. -- things change. [EMAIL PROTECTED]
Re: Alpha machine
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17-Apr-2001 Davide Puricelli wrote: > On Tue, Apr 17, 2001 at 01:09:14PM +0200, Michael Weber wrote: >> On Tue, Apr 17, 2001 at 13:03:44 +0200, Russell Coker wrote: >> > What is the name of the Alpha machine for Debian package development? >> >> faure.d.o > > and lully. Whose last update from the LDAP database was in March 4, according to Joy :-( - -- carlos laviola - icq #55799523 $ chown us:us /your_base -R chown: what you say!! -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE63O2ZZAYCJzUW03IRAl8VAJ9GhIRXSs7sP8aw+oIdFcYIZwyicwCdH6Di ySOz76K6FiPlWpIfY5NgJVg= =gTXB -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Basic lintian errors.
Gavin Hamill writes: > I'm using debhelper, and there's dh_installman listed in debian/rules, but > not dh_installmanpages... 'man dh_installman' is your friend[1]. you need to create a file debian/.manpages and list the manpages to be installed in there. For example: ; pwd /home/decklin/debian/muddleftpd-1.3.9 ; cat debian/muddleftpd.manpages debian/mudpasswd.1 ; You can also use the list-all-manpages-on-the-command-line approach, but I prefer this way. [1] in fact, reading *all* the debhelper documentation before creating dh packages is a good idea, so that you understand what the various tools are doing for you behind the scenes. -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Basic lintian errors.
On Tue, Apr 17, 2001 at 11:23:43PM +0100, Gavin Hamill wrote: > Hullo! :) > > I'm playing with packaging, and lintian's complaining about no manpage for > a binary... but I have a myapp.1 manpage in both the debian/ > control-directory and the root of the source directory.. > > I don't understand what I'm doing wrong :( > > Any pointers would be greatly appreciated.. as otherwise, the package > creation was remarkably successful and painless :) Have a look at the output of dpkg-deb -c . Do you see the manpage there? It should be in /usr/share/man/man[1-8]/. Are you sure that the manpage has a correct .TH line and has the same name as the binary? Have you matched every binary in /[s]bin, /usr/[s]bin, /usr/X11R6/[s]bin and /usr/games to a manpage? (Use the output of dpkg-deb -c for this.) HTH, Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: Basic lintian errors.
On Tue, 17 Apr 2001 [EMAIL PROTECTED] wrote: > Are you using debhelper? If so, are you calling "dh_installmanpages" or > "dh_installman path/to/myapp.1" in debian/rules? Ah :) Tried dh_installmanpages and it worked fine... Since that seems to be a deprecated way of doing things, I'll use the dh_installman method instead... Thank you! But I'm sure it's not the last you'll hear from me :) Gavin.
Re: Policy Questions: Example files in /usr/share/doc
On Tue, Apr 17, 2001 at 05:27:16PM -0400, [EMAIL PROTECTED] wrote:
> Another camp said that this practice should be avoided. The rationale
> was that administrators might do something more drastic to avoid
> populating /usr/share/doc in the first place, like mounting it as a
> read-only partition or using as yet unwritten options to dpkg to
> not unpack files under particular directories. They said it was
> safer to just put the conf file in /etc or whereever it belonged and
> mark it as a conffile and let dpkg's own internal conffile handling
> take care of conflicts.
That's not quite right. The case under consideration is where the
maintainer has decided to maintain the configuration file as a
configuration file, not as a conffile (think of apache's configuration
files, for example: would you really want to have
/etc/apache/httpd.conf as a conffile?!). The second camp said:
put the default configuration in /usr/{share,lib}/$package and copy it
from there in the postinst (or from a configuration program) if
necessary. If it's also a good example, then symlink it from
/usr/share/doc/$package/examples.
I too side with the second camp: the file is not really documentation,
it's got more important functions.
Julian
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
Debian GNU/Linux Developer, see http://people.debian.org/~jdg
Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: Policy Question: Startup Scripts and Config Files
On Tue, Apr 17, 2001 at 06:17:15PM -0300, Henrique M Holschuh wrote: > Most definately yes. You better have a damn very good reason (e.g: the world > will end in a flood of Microsoft-made bovine crap with a mint smell because > their marketing tried to use hordes of purple dinossaurs with shovels to > distribute it) to have a non-conffile anywhere in /etc. s/non-conffile/non-configuration file/ Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: Policy Questions: Example files in /usr/share/doc
On Tue, Apr 17, 2001 at 10:50:28PM +0200, Marc Haber wrote: > Hi, > > the policy upgrading checklist says: > > | - Files in /usr/share/doc may not be referenced by any > |program. If such files are needed, they must be placed in > |/usr/share/package-name/, and symbolic links created as required > |in /usr/share/doc/package-name/ > > Does "any program" include postinst scripts? It is common practice to > put the default config file in /usr/share/doc and copy it to the final > destination in the postinst if a file of that name is not already > there. Yes, it does. There is a concern that if dpkg one day offers the functionality to selectively ignore file trees such as /usr/share/doc, such postinsts will break. There are already people who have been affected by this sort of thing. > I would be forced to move these files to /usr/share, and to add > special code to my maintainer scripts to link them to /usr/share/doc. No you won't; just put them in /usr/share/$package in your rules file, and add the symlink in your rules file. No special maintainer script code needed; dpkg can handle symlinks in .debs. > Or would it be a possible way not to put the default config files to > /usr/share/doc/$package? Where to put "real" examples that are not > accessed by maintainer scripts? Real examples can go in /usr/share/doc/$package/examples if you want. If the default config files are not really interesting as examples, just needed by the postinst, then you can put them in /usr/share/$package (say as "default.conf"), and not bother linking them from /usr/share/doc. HTH, Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: Policy Question: Startup Scripts and Config Files
On Tue, Apr 17, 2001 at 10:43:00PM +0200, Marc Haber wrote: > Hi, > > the upgrade-checklist says: The upgrading-checklist starts by saying: The checklist below has been created to simplify the upgrading process of old packages. Note, that this list is not `official.' If you have doubts about a certain topic, if you need more details, or if you think some other package does not comply with policy, please refer to the Policy Manual. > | - If your package has a daemon startup script in /etc/init.d/, > |and that script has parameters a system administrator may need, > |you need to modify the script to read values from a conffile > |placed in /etc/default/ directory. This conffile maybe sourced > |by the init.d script to determine the configurable values (and > |the conffile may contain only variable settings and comments). Go read the relevant section of the policy itself, I think you will find your question answered. (Search policy for /etc/default, it's section 10.3.2.) To quote: Often there are some values in the ``init.d'' scripts that a system administrator will frequently want to change. While the scripts are frequently conffiles, modifying them requires that the administrator merge in their changes each time the package is upgraded and the conffile changes. To ease the burden on the system administrator, such configurable values should not be placed directly in the script. Instead, they should be placed in a file in ``/etc/default'', which typically will have the same base name as the ``init.d'' script. This extra file can be sourced by the script when the script runs. It must contain only variable settings and comments. > I have a package where the init script contains most of the package's > functionality, and parses a free-format config file > /etc/$PACKAGE.conf. That file is not a shell script and can't be > directly sourced. So you seem fine: you don't have the options in the init file itself. > Can I keep that file as /etc/$PACKAGE, should I move it to > /etc/default (probably not), or do I have to re-work that file as > sourceable file that is then sourced by the init script? Yes, you can keep it. > Do I need to keep the init script as a conffile even if there are "no > admin serviceable parts inside"? Yes. Someone might conceivably want to change bits. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: Basic lintian errors.
On Tue, 17 Apr 2001 [EMAIL PROTECTED] wrote: > > I don't understand what I'm doing wrong :( > > Is your man page actually being installed in the build directory? Actually I don't have a tmp directory, but one with the same name as the package itself... But no sign of the manpage in there anywhere... > Are you using debhelper? If so, are you calling "dh_installmanpages" or > "dh_installman path/to/myapp.1" in debian/rules? I'm using debhelper, and there's dh_installman listed in debian/rules, but not dh_installmanpages... I'm just modifying the debian/ directory created by dh_make -e [EMAIL PROTECTED] -f ../package-1.2.3.tar.gz as directed in http://www.debian.org/doc/maint-guide/ch-first.html Regards, Gavin.
Re: Basic lintian errors.
> I'm playing with packaging, and lintian's complaining about no manpage for > a binary... but I have a myapp.1 manpage in both the debian/ > control-directory and the root of the source directory.. > > I don't understand what I'm doing wrong :( > > Any pointers would be greatly appreciated.. as otherwise, the package > creation was remarkably successful and painless :) Is your man page actually being installed in the build directory? Are you using debhelper? If so, are you calling "dh_installmanpages" or "dh_installman path/to/myapp.1" in debian/rules? Eric
Basic lintian errors.
Hullo! :) I'm playing with packaging, and lintian's complaining about no manpage for a binary... but I have a myapp.1 manpage in both the debian/ control-directory and the root of the source directory.. I don't understand what I'm doing wrong :( Any pointers would be greatly appreciated.. as otherwise, the package creation was remarkably successful and painless :) Kind regards, Gavin.
Re: Policy Questions: Example files in /usr/share/doc
> | - Files in /usr/share/doc may not be referenced by any > |program. If such files are needed, they must be placed in > |/usr/share/package-name/, and symbolic links created as required > |in /usr/share/doc/package-name/ > > Does "any program" include postinst scripts? This was debated here a while ago. There were basically two camps: One camp said that it was ok for the package to do this itself. The rationale was that the system administrator should be able to rm -rf /usr/share/doc/* and have the system still run properly. Since it is unlikely that the administrator would be doing this at the same time as the package is in the process of being installed, this would be ok. Another camp said that this practice should be avoided. The rationale was that administrators might do something more drastic to avoid populating /usr/share/doc in the first place, like mounting it as a read-only partition or using as yet unwritten options to dpkg to not unpack files under particular directories. They said it was safer to just put the conf file in /etc or whereever it belonged and mark it as a conffile and let dpkg's own internal conffile handling take care of conflicts. I'd agree with the second position. > I would be forced to move these files to /usr/share, and to add > special code to my maintainer scripts to link them to /usr/share/doc. No, don't do that. > Or would it be a possible way not to put the default config files to > /usr/share/doc/$package? Where to put "real" examples that are not > accessed by maintainer scripts? Put them in /etc and mark them as conf files. Eric
Re: Policy Questions: Example files in /usr/share/doc
On Tue, 17 Apr 2001, Marc Haber wrote: > the policy upgrading checklist says: > | - Files in /usr/share/doc may not be referenced by any > |program. If such files are needed, they must be placed in > |/usr/share/package-name/, and symbolic links created as required > |in /usr/share/doc/package-name/ > > Does "any program" include postinst scripts? It is common practice to > put the default config file in /usr/share/doc and copy it to the final > destination in the postinst if a file of that name is not already > there. Yes. In some not-so-distant-future, dpkg might be told to not unpack the /usr/share/doc stuff, and your postinst would fail, and we in QA would want your head for the mess. Drop anything you need in your postinst somewhere else than /usr/shade/doc (/usr/share/$package, or maybe /usr/lib/$package -- see FHS) is a good bet. > I would be forced to move these files to /usr/share, and to add > special code to my maintainer scripts to link them to /usr/share/doc. No, you'll have to duplicate them OR add symlinks to the deb file itself (which is probably the best solution). Your maintainer scripts should never even touch /usr/share/doc/* (other than to create the /usr/doc crap). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh pgpXlquZ9nvF3.pgp Description: PGP signature
Re: Policy Question: Startup Scripts and Config Files
On Tue, 17 Apr 2001, Marc Haber wrote: > I have a package where the init script contains most of the package's > functionality, and parses a free-format config file > /etc/$PACKAGE.conf. That file is not a shell script and can't be > directly sourced. > > Can I keep that file as /etc/$PACKAGE, should I move it to > /etc/default (probably not), or do I have to re-work that file as > sourceable file that is then sourced by the init script? I'm not sure. Since the initscript is most of your package, it makes some sense not to dump its stuff in /etc/default. > Do I need to keep the init script as a conffile even if there are "no > admin serviceable parts inside"? Most definately yes. You better have a damn very good reason (e.g: the world will end in a flood of Microsoft-made bovine crap with a mint smell because their marketing tried to use hordes of purple dinossaurs with shovels to distribute it) to have a non-conffile anywhere in /etc. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh pgpzAif5AJVLQ.pgp Description: PGP signature
Policy Questions: Example files in /usr/share/doc
Hi, the policy upgrading checklist says: | - Files in /usr/share/doc may not be referenced by any |program. If such files are needed, they must be placed in |/usr/share/package-name/, and symbolic links created as required |in /usr/share/doc/package-name/ Does "any program" include postinst scripts? It is common practice to put the default config file in /usr/share/doc and copy it to the final destination in the postinst if a file of that name is not already there. I would be forced to move these files to /usr/share, and to add special code to my maintainer scripts to link them to /usr/share/doc. Or would it be a possible way not to put the default config files to /usr/share/doc/$package? Where to put "real" examples that are not accessed by maintainer scripts? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Policy Question: Startup Scripts and Config Files
Hi, the upgrade-checklist says: | - If your package has a daemon startup script in /etc/init.d/, |and that script has parameters a system administrator may need, |you need to modify the script to read values from a conffile |placed in /etc/default/ directory. This conffile maybe sourced |by the init.d script to determine the configurable values (and |the conffile may contain only variable settings and comments). I have a package where the init script contains most of the package's functionality, and parses a free-format config file /etc/$PACKAGE.conf. That file is not a shell script and can't be directly sourced. Can I keep that file as /etc/$PACKAGE, should I move it to /etc/default (probably not), or do I have to re-work that file as sourceable file that is then sourced by the init script? Do I need to keep the init script as a conffile even if there are "no admin serviceable parts inside"? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Re: Basic lintian errors.
On Tue, Apr 17, 2001 at 11:23:43PM +0100, Gavin Hamill wrote: > Hullo! :) > > I'm playing with packaging, and lintian's complaining about no manpage for > a binary... but I have a myapp.1 manpage in both the debian/ > control-directory and the root of the source directory.. > > I don't understand what I'm doing wrong :( > > Any pointers would be greatly appreciated.. as otherwise, the package > creation was remarkably successful and painless :) Have a look at the output of dpkg-deb -c . Do you see the manpage there? It should be in /usr/share/man/man[1-8]/. Are you sure that the manpage has a correct .TH line and has the same name as the binary? Have you matched every binary in /[s]bin, /usr/[s]bin, /usr/X11R6/[s]bin and /usr/games to a manpage? (Use the output of dpkg-deb -c for this.) HTH, Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Basic lintian errors.
On Tue, 17 Apr 2001 [EMAIL PROTECTED] wrote: > Are you using debhelper? If so, are you calling "dh_installmanpages" or > "dh_installman path/to/myapp.1" in debian/rules? Ah :) Tried dh_installmanpages and it worked fine... Since that seems to be a deprecated way of doing things, I'll use the dh_installman method instead... Thank you! But I'm sure it's not the last you'll hear from me :) Gavin. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Policy Questions: Example files in /usr/share/doc
On Tue, Apr 17, 2001 at 05:27:16PM -0400, [EMAIL PROTECTED] wrote:
> Another camp said that this practice should be avoided. The rationale
> was that administrators might do something more drastic to avoid
> populating /usr/share/doc in the first place, like mounting it as a
> read-only partition or using as yet unwritten options to dpkg to
> not unpack files under particular directories. They said it was
> safer to just put the conf file in /etc or whereever it belonged and
> mark it as a conffile and let dpkg's own internal conffile handling
> take care of conflicts.
That's not quite right. The case under consideration is where the
maintainer has decided to maintain the configuration file as a
configuration file, not as a conffile (think of apache's configuration
files, for example: would you really want to have
/etc/apache/httpd.conf as a conffile?!). The second camp said:
put the default configuration in /usr/{share,lib}/$package and copy it
from there in the postinst (or from a configuration program) if
necessary. If it's also a good example, then symlink it from
/usr/share/doc/$package/examples.
I too side with the second camp: the file is not really documentation,
it's got more important functions.
Julian
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
Debian GNU/Linux Developer, see http://people.debian.org/~jdg
Donate free food to the world's hungry: see http://www.thehungersite.com/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Policy Question: Startup Scripts and Config Files
On Tue, Apr 17, 2001 at 06:17:15PM -0300, Henrique M Holschuh wrote: > Most definately yes. You better have a damn very good reason (e.g: the world > will end in a flood of Microsoft-made bovine crap with a mint smell because > their marketing tried to use hordes of purple dinossaurs with shovels to > distribute it) to have a non-conffile anywhere in /etc. s/non-conffile/non-configuration file/ Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Policy Questions: Example files in /usr/share/doc
On Tue, Apr 17, 2001 at 10:50:28PM +0200, Marc Haber wrote: > Hi, > > the policy upgrading checklist says: > > | - Files in /usr/share/doc may not be referenced by any > |program. If such files are needed, they must be placed in > |/usr/share/package-name/, and symbolic links created as required > |in /usr/share/doc/package-name/ > > Does "any program" include postinst scripts? It is common practice to > put the default config file in /usr/share/doc and copy it to the final > destination in the postinst if a file of that name is not already > there. Yes, it does. There is a concern that if dpkg one day offers the functionality to selectively ignore file trees such as /usr/share/doc, such postinsts will break. There are already people who have been affected by this sort of thing. > I would be forced to move these files to /usr/share, and to add > special code to my maintainer scripts to link them to /usr/share/doc. No you won't; just put them in /usr/share/$package in your rules file, and add the symlink in your rules file. No special maintainer script code needed; dpkg can handle symlinks in .debs. > Or would it be a possible way not to put the default config files to > /usr/share/doc/$package? Where to put "real" examples that are not > accessed by maintainer scripts? Real examples can go in /usr/share/doc/$package/examples if you want. If the default config files are not really interesting as examples, just needed by the postinst, then you can put them in /usr/share/$package (say as "default.conf"), and not bother linking them from /usr/share/doc. HTH, Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Policy Question: Startup Scripts and Config Files
On Tue, Apr 17, 2001 at 10:43:00PM +0200, Marc Haber wrote: > Hi, > > the upgrade-checklist says: The upgrading-checklist starts by saying: The checklist below has been created to simplify the upgrading process of old packages. Note, that this list is not `official.' If you have doubts about a certain topic, if you need more details, or if you think some other package does not comply with policy, please refer to the Policy Manual. > | - If your package has a daemon startup script in /etc/init.d/, > |and that script has parameters a system administrator may need, > |you need to modify the script to read values from a conffile > |placed in /etc/default/ directory. This conffile maybe sourced > |by the init.d script to determine the configurable values (and > |the conffile may contain only variable settings and comments). Go read the relevant section of the policy itself, I think you will find your question answered. (Search policy for /etc/default, it's section 10.3.2.) To quote: Often there are some values in the ``init.d'' scripts that a system administrator will frequently want to change. While the scripts are frequently conffiles, modifying them requires that the administrator merge in their changes each time the package is upgraded and the conffile changes. To ease the burden on the system administrator, such configurable values should not be placed directly in the script. Instead, they should be placed in a file in ``/etc/default'', which typically will have the same base name as the ``init.d'' script. This extra file can be sourced by the script when the script runs. It must contain only variable settings and comments. > I have a package where the init script contains most of the package's > functionality, and parses a free-format config file > /etc/$PACKAGE.conf. That file is not a shell script and can't be > directly sourced. So you seem fine: you don't have the options in the init file itself. > Can I keep that file as /etc/$PACKAGE, should I move it to > /etc/default (probably not), or do I have to re-work that file as > sourceable file that is then sourced by the init script? Yes, you can keep it. > Do I need to keep the init script as a conffile even if there are "no > admin serviceable parts inside"? Yes. Someone might conceivably want to change bits. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Basic lintian errors.
On Tue, 17 Apr 2001 [EMAIL PROTECTED] wrote: > > I don't understand what I'm doing wrong :( > > Is your man page actually being installed in the build directory? Actually I don't have a tmp directory, but one with the same name as the package itself... But no sign of the manpage in there anywhere... > Are you using debhelper? If so, are you calling "dh_installmanpages" or > "dh_installman path/to/myapp.1" in debian/rules? I'm using debhelper, and there's dh_installman listed in debian/rules, but not dh_installmanpages... I'm just modifying the debian/ directory created by dh_make -e [EMAIL PROTECTED] -f ../package-1.2.3.tar.gz as directed in http://www.debian.org/doc/maint-guide/ch-first.html Regards, Gavin. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Basic lintian errors.
> I'm playing with packaging, and lintian's complaining about no manpage for > a binary... but I have a myapp.1 manpage in both the debian/ > control-directory and the root of the source directory.. > > I don't understand what I'm doing wrong :( > > Any pointers would be greatly appreciated.. as otherwise, the package > creation was remarkably successful and painless :) Is your man page actually being installed in the build directory? Are you using debhelper? If so, are you calling "dh_installmanpages" or "dh_installman path/to/myapp.1" in debian/rules? Eric -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Basic lintian errors.
Hullo! :) I'm playing with packaging, and lintian's complaining about no manpage for a binary... but I have a myapp.1 manpage in both the debian/ control-directory and the root of the source directory.. I don't understand what I'm doing wrong :( Any pointers would be greatly appreciated.. as otherwise, the package creation was remarkably successful and painless :) Kind regards, Gavin. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shlibs:Depends
OK, thanks for this good piece of advice. On Fri, Apr 13, 2001 at 06:10:22PM -0700, Mike Markley wrote: > On Fri, Apr 13, 2001 at 04:30:15PM -0800, Britton <[EMAIL PROTECTED]> spake > forth: > > > > > It actually works with tcl 8.0, 8.1 and 8.2 you are right. So what about : > > > > > > Depends: tcl8.0 | tcl8.1 | tcl8.2 > > > > Or mayby just depend on a version greater than 8.0, as you do with > > debhelper in you build depend. But Mayby tcl breaks backward > > compatability a lot and you thing it would be better without that, sort of > > a judgement call I guess. > > > Couple of problems with this... > 1) tcl8.1 doesn't exist in Debian > 2) tcl breaks backwards compatability a *lot* > 3) because of #2, there are separate packages for 8.0, 8.2, and 8.3; >therefore, a simple Depends: tcl (>= 8.0) will not work. > > All in all, "Depends: tclsh | tcl8.2" should generally work for > straightforward > scripts, as the language doesn't tend to change that much between releases, > just the API for the library and various internals. All of the tcl packages > Provide: tclsh, so that'll work for scripts which don't have any insanity > preventing them from working with all modern TCLs. > > Note that lintian complains about depending only on a virtual package, and > while a quick glance doesn't find language in policy which forbids it, that > is just a quick glance ;). > > > -- > Mike Markley <[EMAIL PROTECTED]> > GPG: 0x3B047084 7FC7 0DC0 EF31 DF83 7313 FE2B 77A8 F36A 3B04 7084 > > "Logic and practical information do not seem to apply here." > "You admit that?" > "To deny the facts would be illogical, Doctor" > - Spock and McCoy, "A Piece of the Action", stardate unknown > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- Eric VAN BUGGENHAUT [EMAIL PROTECTED]
Re: Policy Questions: Example files in /usr/share/doc
> | - Files in /usr/share/doc may not be referenced by any > |program. If such files are needed, they must be placed in > |/usr/share/package-name/, and symbolic links created as required > |in /usr/share/doc/package-name/ > > Does "any program" include postinst scripts? This was debated here a while ago. There were basically two camps: One camp said that it was ok for the package to do this itself. The rationale was that the system administrator should be able to rm -rf /usr/share/doc/* and have the system still run properly. Since it is unlikely that the administrator would be doing this at the same time as the package is in the process of being installed, this would be ok. Another camp said that this practice should be avoided. The rationale was that administrators might do something more drastic to avoid populating /usr/share/doc in the first place, like mounting it as a read-only partition or using as yet unwritten options to dpkg to not unpack files under particular directories. They said it was safer to just put the conf file in /etc or whereever it belonged and mark it as a conffile and let dpkg's own internal conffile handling take care of conflicts. I'd agree with the second position. > I would be forced to move these files to /usr/share, and to add > special code to my maintainer scripts to link them to /usr/share/doc. No, don't do that. > Or would it be a possible way not to put the default config files to > /usr/share/doc/$package? Where to put "real" examples that are not > accessed by maintainer scripts? Put them in /etc and mark them as conf files. Eric -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Policy Questions: Example files in /usr/share/doc
On Tue, 17 Apr 2001, Marc Haber wrote: > the policy upgrading checklist says: > | - Files in /usr/share/doc may not be referenced by any > |program. If such files are needed, they must be placed in > |/usr/share/package-name/, and symbolic links created as required > |in /usr/share/doc/package-name/ > > Does "any program" include postinst scripts? It is common practice to > put the default config file in /usr/share/doc and copy it to the final > destination in the postinst if a file of that name is not already > there. Yes. In some not-so-distant-future, dpkg might be told to not unpack the /usr/share/doc stuff, and your postinst would fail, and we in QA would want your head for the mess. Drop anything you need in your postinst somewhere else than /usr/shade/doc (/usr/share/$package, or maybe /usr/lib/$package -- see FHS) is a good bet. > I would be forced to move these files to /usr/share, and to add > special code to my maintainer scripts to link them to /usr/share/doc. No, you'll have to duplicate them OR add symlinks to the deb file itself (which is probably the best solution). Your maintainer scripts should never even touch /usr/share/doc/* (other than to create the /usr/doc crap). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh PGP signature
Re: Policy Question: Startup Scripts and Config Files
On Tue, 17 Apr 2001, Marc Haber wrote: > I have a package where the init script contains most of the package's > functionality, and parses a free-format config file > /etc/$PACKAGE.conf. That file is not a shell script and can't be > directly sourced. > > Can I keep that file as /etc/$PACKAGE, should I move it to > /etc/default (probably not), or do I have to re-work that file as > sourceable file that is then sourced by the init script? I'm not sure. Since the initscript is most of your package, it makes some sense not to dump its stuff in /etc/default. > Do I need to keep the init script as a conffile even if there are "no > admin serviceable parts inside"? Most definately yes. You better have a damn very good reason (e.g: the world will end in a flood of Microsoft-made bovine crap with a mint smell because their marketing tried to use hordes of purple dinossaurs with shovels to distribute it) to have a non-conffile anywhere in /etc. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh PGP signature
Policy Questions: Example files in /usr/share/doc
Hi, the policy upgrading checklist says: | - Files in /usr/share/doc may not be referenced by any |program. If such files are needed, they must be placed in |/usr/share/package-name/, and symbolic links created as required |in /usr/share/doc/package-name/ Does "any program" include postinst scripts? It is common practice to put the default config file in /usr/share/doc and copy it to the final destination in the postinst if a file of that name is not already there. I would be forced to move these files to /usr/share, and to add special code to my maintainer scripts to link them to /usr/share/doc. Or would it be a possible way not to put the default config files to /usr/share/doc/$package? Where to put "real" examples that are not accessed by maintainer scripts? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Policy Question: Startup Scripts and Config Files
Hi, the upgrade-checklist says: | - If your package has a daemon startup script in /etc/init.d/, |and that script has parameters a system administrator may need, |you need to modify the script to read values from a conffile |placed in /etc/default/ directory. This conffile maybe sourced |by the init.d script to determine the configurable values (and |the conffile may contain only variable settings and comments). I have a package where the init script contains most of the package's functionality, and parses a free-format config file /etc/$PACKAGE.conf. That file is not a shell script and can't be directly sourced. Can I keep that file as /etc/$PACKAGE, should I move it to /etc/default (probably not), or do I have to re-work that file as sourceable file that is then sourced by the init script? Do I need to keep the init script as a conffile even if there are "no admin serviceable parts inside"? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shlibs:Depends
OK, thanks for this good piece of advice. On Fri, Apr 13, 2001 at 06:10:22PM -0700, Mike Markley wrote: > On Fri, Apr 13, 2001 at 04:30:15PM -0800, Britton <[EMAIL PROTECTED]> spake forth: > > > > > It actually works with tcl 8.0, 8.1 and 8.2 you are right. So what about : > > > > > > Depends: tcl8.0 | tcl8.1 | tcl8.2 > > > > Or mayby just depend on a version greater than 8.0, as you do with > > debhelper in you build depend. But Mayby tcl breaks backward > > compatability a lot and you thing it would be better without that, sort of > > a judgement call I guess. > > > Couple of problems with this... > 1) tcl8.1 doesn't exist in Debian > 2) tcl breaks backwards compatability a *lot* > 3) because of #2, there are separate packages for 8.0, 8.2, and 8.3; >therefore, a simple Depends: tcl (>= 8.0) will not work. > > All in all, "Depends: tclsh | tcl8.2" should generally work for straightforward > scripts, as the language doesn't tend to change that much between releases, > just the API for the library and various internals. All of the tcl packages > Provide: tclsh, so that'll work for scripts which don't have any insanity > preventing them from working with all modern TCLs. > > Note that lintian complains about depending only on a virtual package, and > while a quick glance doesn't find language in policy which forbids it, that > is just a quick glance ;). > > > -- > Mike Markley <[EMAIL PROTECTED]> > GPG: 0x3B047084 7FC7 0DC0 EF31 DF83 7313 FE2B 77A8 F36A 3B04 7084 > > "Logic and practical information do not seem to apply here." > "You admit that?" > "To deny the facts would be illogical, Doctor" > - Spock and McCoy, "A Piece of the Action", stardate unknown > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- Eric VAN BUGGENHAUT [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Custom package versioning
On Tue, 17 Apr 2001, Amaya wrote: > At work, we are making custom Debian packages and we need a special > versioning system so that apt does not try to replace our package with > a newer upstream one. > > I would like to know if there's a standard way to proceed, apart from > setting the debian version to customX, which is good, but doesn not > deal with the fact that dpkg will try to replace the package with a > newer upstream one. At my work, we pulled a copy of stable and placed it on a mirror. Then we created our own "dist" with two sections - bofa (Bank of America) and backports. The first is for truly local packabes, and the second is for "Debian upstream" packages that we recompile for various reasons (either stuff from unstable, or slight mods, etc.) We've got a script to regen our packages files every time we drop something new into the mirror. We name our packages "version-XlocalY" Pros: complete control over what gets installed on your systems fast internal mirror is faster and saves bandwidth for everybody Cons: relatively labor intensive to keep current on point releases and security.d.o (but we've got really strong change control, and we know what's out there!) HTH, tony
Re: Custom package versioning
On Tue, 17 Apr 2001, Amaya wrote: > At work, we are making custom Debian packages and we need a special > versioning system so that apt does not try to replace our package with > a newer upstream one. > > I would like to know if there's a standard way to proceed, apart from > setting the debian version to customX, which is good, but doesn not > deal with the fact that dpkg will try to replace the package with a > newer upstream one. At my work, we pulled a copy of stable and placed it on a mirror. Then we created our own "dist" with two sections - bofa (Bank of America) and backports. The first is for truly local packabes, and the second is for "Debian upstream" packages that we recompile for various reasons (either stuff from unstable, or slight mods, etc.) We've got a script to regen our packages files every time we drop something new into the mirror. We name our packages "version-XlocalY" Pros: complete control over what gets installed on your systems fast internal mirror is faster and saves bandwidth for everybody Cons: relatively labor intensive to keep current on point releases and security.d.o (but we've got really strong change control, and we know what's out there!) HTH, tony -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Alpha machine
On Tue, Apr 17, 2001 at 13:26:56 +0200, Davide Puricelli wrote: > On Tue, Apr 17, 2001 at 01:09:14PM +0200, Michael Weber wrote: > > On Tue, Apr 17, 2001 at 13:03:44 +0200, Russell Coker wrote: > > > What is the name of the Alpha machine for Debian package development? > > > > faure.d.o > > http://db.debian.org/machines.cgi > > and lully. Then someone should probably update machines.cgi, it still says "CPU card failed" for lully. [Cc'd to -admin] Cheers, Michael -- /~\ ASCII ribbon | inbox, n.: \ / campaign |A catch basin for everything you don't want to deal X against |with, but are afraid to throw away. / \ HTML mail| pgpFqYNjSls2H.pgp Description: PGP signature
Re: Alpha machine
On Tue, Apr 17, 2001 at 01:09:14PM +0200, Michael Weber wrote: > On Tue, Apr 17, 2001 at 13:03:44 +0200, Russell Coker wrote: > > What is the name of the Alpha machine for Debian package development? > > faure.d.o > > http://db.debian.org/machines.cgi > > Cheers, > M/ > -- > /~\ ASCII ribbon | "i have decided to release the first 24GB of my genetic > \ / campaign | code under the Artistic License. since this is DFSG > X against | compatible, could it go in main?" > / \ HTML mail| -- debian-devel <[EMAIL PROTECTED]> > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] and lully. Cheers, -- Davide Puricelli, [EMAIL PROTECTED] | [EMAIL PROTECTED] Debian Developer: [EMAIL PROTECTED] | http://www.debian.org PGP key: finger [EMAIL PROTECTED] UIN: 2885982 pgplh7QrsINcH.pgp Description: PGP signature
Re: Alpha machine
On Tue, Apr 17, 2001 at 13:03:44 +0200, Russell Coker wrote: > What is the name of the Alpha machine for Debian package development? faure.d.o http://db.debian.org/machines.cgi Cheers, M/ -- /~\ ASCII ribbon | "i have decided to release the first 24GB of my genetic \ / campaign | code under the Artistic License. since this is DFSG X against | compatible, could it go in main?" / \ HTML mail| -- debian-devel <[EMAIL PROTECTED]>
Alpha machine
I'm asking on d-m because this may be too stupid for d-d. What is the name of the Alpha machine for Debian package development? It seems that my programs operate differently on Alpha due to some subtleties of floating point math and I'd like to try it out myself... I have sent in my ssh key so my account should already be active. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
Re: Custom package versioning
On Tue, Apr 17, 2001 at 11:18:32AM +0200, Amaya wrote: > Hello all, > > At work, we are making custom Debian packages and we need a special versioning > system so that apt does not try to replace our package with a newer upstream > one. > > I would like to know if there's a standard way to proceed, apart from setting > the debian version to customX, which is good, but doesn not deal with the fact > that dpkg will try to replace the package with a newer upstream one. > > Thanks in advance for any input or ideas. I would suggest that you keep to the standard versioning scheme (adding your custom version number _after_ the debian version, and just place the packages on hold. If your packages are completely incompatible, you should probably just change the name of the package itself. -brad
Re: Custom package versioning
On Tue, Apr 17, 2001 at 11:18:32AM +0200, Amaya wrote: > Hello all, > > At work, we are making custom Debian packages and we need a special versioning > system so that apt does not try to replace our package with a newer upstream > one. > > I would like to know if there's a standard way to proceed, apart from setting > the debian version to customX, which is good, but doesn not deal with the fact > that dpkg will try to replace the package with a newer upstream one. You could use an epoch. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: Alpha machine
On Tue, Apr 17, 2001 at 13:26:56 +0200, Davide Puricelli wrote: > On Tue, Apr 17, 2001 at 01:09:14PM +0200, Michael Weber wrote: > > On Tue, Apr 17, 2001 at 13:03:44 +0200, Russell Coker wrote: > > > What is the name of the Alpha machine for Debian package development? > > > > faure.d.o > > http://db.debian.org/machines.cgi > > and lully. Then someone should probably update machines.cgi, it still says "CPU card failed" for lully. [Cc'd to -admin] Cheers, Michael -- /~\ ASCII ribbon | inbox, n.: \ / campaign |A catch basin for everything you don't want to deal X against |with, but are afraid to throw away. / \ HTML mail| PGP signature
Custom package versioning
Hello all, At work, we are making custom Debian packages and we need a special versioning system so that apt does not try to replace our package with a newer upstream one. I would like to know if there's a standard way to proceed, apart from setting the debian version to customX, which is good, but doesn not deal with the fact that dpkg will try to replace the package with a newer upstream one. Thanks in advance for any input or ideas. Amaya -- Amaya M. Rodrigo Sastre Sysadmin @ Andago.com Proudly running Debian GNU/Linux I think I'm schizophrenic. One half of me's paranoid and the other half's out to get him.
Re: Alpha machine
On Tue, Apr 17, 2001 at 01:09:14PM +0200, Michael Weber wrote: > On Tue, Apr 17, 2001 at 13:03:44 +0200, Russell Coker wrote: > > What is the name of the Alpha machine for Debian package development? > > faure.d.o > > http://db.debian.org/machines.cgi > > Cheers, > M/ > -- > /~\ ASCII ribbon | "i have decided to release the first 24GB of my genetic > \ / campaign | code under the Artistic License. since this is DFSG > X against | compatible, could it go in main?" > / \ HTML mail| -- debian-devel <[EMAIL PROTECTED]> > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] and lully. Cheers, -- Davide Puricelli, [EMAIL PROTECTED] | [EMAIL PROTECTED] Debian Developer: [EMAIL PROTECTED] | http://www.debian.org PGP key: finger [EMAIL PROTECTED] UIN: 2885982 PGP signature
Re: Alpha machine
On Tue, Apr 17, 2001 at 13:03:44 +0200, Russell Coker wrote: > What is the name of the Alpha machine for Debian package development? faure.d.o http://db.debian.org/machines.cgi Cheers, M/ -- /~\ ASCII ribbon | "i have decided to release the first 24GB of my genetic \ / campaign | code under the Artistic License. since this is DFSG X against | compatible, could it go in main?" / \ HTML mail| -- debian-devel <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Alpha machine
I'm asking on d-m because this may be too stupid for d-d. What is the name of the Alpha machine for Debian package development? It seems that my programs operate differently on Alpha due to some subtleties of floating point math and I'd like to try it out myself... I have sent in my ssh key so my account should already be active. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lintian -i file.changes error
On Mon, Apr 16, 2001 at 01:21:45PM -0700, Sean 'Shaleh' Perry wrote:
> >
> > To mistake a hard link for a zero-length file is sloppy coding.
> > This is a bug in lintian.
> >
>
> lintian gets its information from tar's output. A hardlink is shown as a zero
> byte file.
So lintian does something like ar .deb; tar ztf data.tar.gz?
If so, could lintian do something like dpkg-deb -c .deb, which
indicates when files are hard links ("linkname links to filename") in
its output (and soft links with "linkname -> filename").
Julian
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
Debian GNU/Linux Developer, see http://people.debian.org/~jdg
Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: Custom package versioning
On Tue, Apr 17, 2001 at 11:18:32AM +0200, Amaya wrote: > Hello all, > > At work, we are making custom Debian packages and we need a special versioning > system so that apt does not try to replace our package with a newer upstream > one. > > I would like to know if there's a standard way to proceed, apart from setting > the debian version to customX, which is good, but doesn not deal with the fact > that dpkg will try to replace the package with a newer upstream one. > > Thanks in advance for any input or ideas. I would suggest that you keep to the standard versioning scheme (adding your custom version number _after_ the debian version, and just place the packages on hold. If your packages are completely incompatible, you should probably just change the name of the package itself. -brad -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Custom package versioning
On Tue, Apr 17, 2001 at 11:18:32AM +0200, Amaya wrote: > Hello all, > > At work, we are making custom Debian packages and we need a special versioning > system so that apt does not try to replace our package with a newer upstream > one. > > I would like to know if there's a standard way to proceed, apart from setting > the debian version to customX, which is good, but doesn not deal with the fact > that dpkg will try to replace the package with a newer upstream one. You could use an epoch. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Username and Password for logon client
On Mon, Apr 16, 2001 at 03:13:09PM -0700, Sean 'Shaleh' Perry wrote: > b) init script stuff, see update-inetd manpage. I believe update-rc.d would be more appropriate. :) -- Karl Söderström [EMAIL PROTECTED] http://www.xanadunet.net [EMAIL PROTECTED] http://www.debian.org
Custom package versioning
Hello all, At work, we are making custom Debian packages and we need a special versioning system so that apt does not try to replace our package with a newer upstream one. I would like to know if there's a standard way to proceed, apart from setting the debian version to customX, which is good, but doesn not deal with the fact that dpkg will try to replace the package with a newer upstream one. Thanks in advance for any input or ideas. Amaya -- Amaya M. Rodrigo Sastre Sysadmin @ Andago.com Proudly running Debian GNU/Linux I think I'm schizophrenic. One half of me's paranoid and the other half's out to get him. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lintian -i file.changes error
On Mon, Apr 16, 2001 at 01:21:45PM -0700, Sean 'Shaleh' Perry wrote:
> >
> > To mistake a hard link for a zero-length file is sloppy coding.
> > This is a bug in lintian.
> >
>
> lintian gets its information from tar's output. A hardlink is shown as a zero
> byte file.
So lintian does something like ar .deb; tar ztf data.tar.gz?
If so, could lintian do something like dpkg-deb -c .deb, which
indicates when files are hard links ("linkname links to filename") in
its output (and soft links with "linkname -> filename").
Julian
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
Debian GNU/Linux Developer, see http://people.debian.org/~jdg
Donate free food to the world's hungry: see http://www.thehungersite.com/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Username and Password for logon client
On Mon, Apr 16, 2001 at 03:13:09PM -0700, Sean 'Shaleh' Perry wrote: > b) init script stuff, see update-inetd manpage. I believe update-rc.d would be more appropriate. :) -- Karl Söderström [EMAIL PROTECTED] http://www.xanadunet.net [EMAIL PROTECTED] http://www.debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
