Hi!
I am a bit unsure about how to name two upcoming packages of mine, and
wouldn't mind a few suggests :)
So, I have this one package (ccze), which is extensible via plugins,
and I have two, separately maintained, extensions: one for running
perl scriptlets, and another for running slang
Hello folks,
I've packaged the the Baramond TrueType Font set available under
a freeware license over here: http://geocities.com/baramondfont/
I've written an email to the upstream author asking for more information
about the license of this font set, for now I got no answer, let's wait
some
Hi,
how can a package learn about its current version number?
Parsing /usr/share/doc/$PACKAGE/changelog.gz is out of the question
since /usr/share/doc need not be present, and calling dpkg --list
$PACKAGE and parsing its output looks like bad overkill.
Does a maintainer script know the package
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Mar 04, 2003 at 01:41:58PM +0100, Marc Haber wrote:
how can a package learn about its current version number?
Package information is stored in /var/lib/dpkg/available.
There is already a package parsing this information: grep-dctrl
You can do
En réponse à Marc Haber [EMAIL PROTECTED]:
Hi,
Hi,
how can a package learn about its current version number?
Parsing /usr/share/doc/$PACKAGE/changelog.gz is out of the question
since /usr/share/doc need not be present, and calling dpkg --list
$PACKAGE and parsing its output looks like
On Tue, 04 Mar 2003, Bastian Kleineidam wrote:
On Tue, Mar 04, 2003 at 01:41:58PM +0100, Marc Haber wrote:
how can a package learn about its current version number?
Package information is stored in /var/lib/dpkg/available.
No. Do not skip the proper interface layers. Use dpkg to get that
Colin Watson (2003-03-04 14:06:07 +) :
On Tue, Mar 04, 2003 at 02:14:59PM +0100, Bastian Kleineidam wrote:
[...]
# example: current bash version number
BASH_VERSION=`grep-available -P -s Version -n -r '^bash$'`
That will be wrong in the event that somebody has run 'dselect
update' but
On Tue, 4 Mar 2003 07:16:11 -0600, Graham Wilson [EMAIL PROTECTED]
wrote:
On Tue, Mar 04, 2003 at 01:41:58PM +0100, Marc Haber wrote:
Parsing /usr/share/doc/$PACKAGE/changelog.gz is out of the question
since /usr/share/doc need not be present, and calling dpkg --list
$PACKAGE and parsing its
On Tue, Mar 04, 2003 at 05:02:22PM +0100, Marc Haber wrote:
On Tue, 04 Mar 2003 14:16:34 +0100 (CET), J?r?me Marant
[EMAIL PROTECTED] wrote:
IIRC you can get it from the postinst parameters. You can have a look
to the policy, in maintainers scripts section.
I thought so as well, but it
Marc,
Well, I wouldn't have posted without first consulting policy and
developer's reference. Section 6.4 doesn't seem to document any
maintainer script of the package being installed being called with the
new version number as a parameter, so I was actually hoping that dpkg
sends that
Roland Mas wrote:
Colin Watson (2003-03-04 14:06:07 +) :
On Tue, Mar 04, 2003 at 02:14:59PM +0100, Bastian Kleineidam wrote:
How about the following?
BASH_VERSION=$(dpkg -s bash | awk '/^Version:/ { print $2 }')
if [ $(dpkg -s bash | awk '/^Status:/ { print $3 $4 }') == ok installed ]
Hello,
On Tue, Mar 04, 2003 at 11:04:29AM +0100, Gergely Nagy wrote:
I am a bit unsure about how to name two upcoming packages of mine, and
wouldn't mind a few suggests :)
So, I have this one package (ccze), which is extensible via plugins,
and I have two, separately maintained, extensions:
Now that my new maintainer application has been approved, I want to
start the process of changing the maintainer field in my packages to use
my @d.o address rather than my personal address.
What is the recommended practice on uploading new versions of packages
just for minor changes like this?
On Tue, Mar 04, 2003 at 02:24:17PM -0600, Kenneth Pronovici wrote:
Now that my new maintainer application has been approved,
congratulations.
What is the recommended practice on uploading new versions of packages
just for minor changes like this? Should I upload new versions of all
of my
Johannes Rohr [EMAIL PROTECTED] writes:
Well, I don't know. Until today I've contacted them three times and
there as been no response except for an acknowledgement of receipt.
Therefore I don't think they'd turn out to be more responsive if I came
begging for money...
It's actually called
On Tuesday 04 March 2003 12:45, Michael Banck wrote:
What is the recommended practice on uploading new versions of packages
just for minor changes like this? Should I upload new versions of all
of my packages, or wait to upload each package until there is a more
significant user-visible
On Tue, 4 Mar 2003 17:34:47 +0100, Simon Richter [EMAIL PROTECTED]
wrote:
Well, I wouldn't have posted without first consulting policy and
developer's reference. Section 6.4 doesn't seem to document any
maintainer script of the package being installed being called with the
new version number
On Tue, 4 Mar 2003 16:41:48 +, Colin Watson [EMAIL PROTECTED]
wrote:
On Tue, Mar 04, 2003 at 05:02:22PM +0100, Marc Haber wrote:
I thought so as well, but it looks like postinst is only called with
the most recently configured version, not with the current version.
Why not just preprocess
On Tue, 04 Mar 2003 17:46:40 +0100 (CET), Jérôme Marant
[EMAIL PROTECTED] wrote:
En réponse à Sven Luther [EMAIL PROTECTED]:
No, it is not. You just need to use the $1 argument to postinst, as
Jerome told you.
IIRC, it is $2.
Policy 6.4 says:
postinst configure most-recently-configured-version
On Tue, 4 Mar 2003 16:41:48 +, Colin Watson [EMAIL PROTECTED]
wrote:
Why not just preprocess the postinst in debian/rules to embed its own
version number directly into it?
Nice idea, thanks!
Is an executeable script (for example an init script) allowed to parse
I don't know if there is a policy on this. I'd recommend switching to
your @d.o address as you're doing regular uploads. If by the time of the
freeze there are still packages left with your old address, an upload
just to fix that is alright. That's just MHO, YMMV.
this is probably the
On Tue, Mar 04, 2003 at 05:01:36PM +0100, Marc Haber wrote:
On Tue, 4 Mar 2003 07:16:11 -0600, Graham Wilson [EMAIL PROTECTED] wrote:
dpkg -l PACKAGE | awk '$2 ~ /PACKAGE/ { print $3 }'
Well, I just said that I consider foo to be bad overkill, and you
proceed to posting foo without any
On Fri, Feb 28, 2003 at 11:38:33PM -0500, Joey Hess wrote:
Bastian Kleineidam wrote:
Hmm, dh_make is trying to do a similar approach. Why not use that way?
I like to have the original .tar.gz exactly as I downloaded it. dh_make
unpacks the source and repacks it to a new .orig.tar.gz.
On Tue, Mar 04, 2003 at 01:41:58PM +0100, Marc Haber wrote:
how can a package learn about its current version number?
Parsing /usr/share/doc/$PACKAGE/changelog.gz is out of the question
since /usr/share/doc need not be present, and calling dpkg --list
$PACKAGE and parsing its output looks
I demand that Colin Watson may or may not have written...
On Tue, Mar 04, 2003 at 11:52:09PM +0100, Marc Haber wrote:
On Tue, 4 Mar 2003 16:41:48 +, Colin Watson [EMAIL PROTECTED]
wrote:
Why not just preprocess the postinst in debian/rules to embed its own
version number directly into
Hello folks,
I've packaged the the Baramond TrueType Font set available under
a freeware license over here: http://geocities.com/baramondfont/
I've written an email to the upstream author asking for more information
about the license of this font set, for now I got no answer, let's wait
some
Hi,
how can a package learn about its current version number?
Parsing /usr/share/doc/$PACKAGE/changelog.gz is out of the question
since /usr/share/doc need not be present, and calling dpkg --list
$PACKAGE and parsing its output looks like bad overkill.
Does a maintainer script know the package
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Mar 04, 2003 at 01:41:58PM +0100, Marc Haber wrote:
how can a package learn about its current version number?
Package information is stored in /var/lib/dpkg/available.
There is already a package parsing this information: grep-dctrl
You can do
On Tue, Mar 04, 2003 at 01:41:58PM +0100, Marc Haber wrote:
Parsing /usr/share/doc/$PACKAGE/changelog.gz is out of the question
since /usr/share/doc need not be present, and calling dpkg --list
$PACKAGE and parsing its output looks like bad overkill.
dpkg -l PACKAGE | awk '$2 ~ /PACKAGE/ {
On Tue, 04 Mar 2003, Bastian Kleineidam wrote:
On Tue, Mar 04, 2003 at 01:41:58PM +0100, Marc Haber wrote:
how can a package learn about its current version number?
Package information is stored in /var/lib/dpkg/available.
No. Do not skip the proper interface layers. Use dpkg to get that
On Tue, Mar 04, 2003 at 02:14:59PM +0100, Bastian Kleineidam wrote:
On Tue, Mar 04, 2003 at 01:41:58PM +0100, Marc Haber wrote:
how can a package learn about its current version number?
Package information is stored in /var/lib/dpkg/available.
Information about what's installed is in
On Tue, 04 Mar 2003, Henrique de Moraes Holschuh wrote:
Not contrib, unless you package is a simple installer for the fonts.
non-free, yes, if the license allows redistribution at all (I didn't check).
The package provides all four fonts and the license should allow
redistibution (I think --
On Tue, 4 Mar 2003 10:40:52 -0300, Henrique de Moraes Holschuh
[EMAIL PROTECTED] wrote:
No. Do not skip the proper interface layers. Use dpkg to get that
information.
Calling dpkg is actually the recommended way to do this? Can I call
dpkg --list from a postinst script without having it explode?
Colin Watson (2003-03-04 14:06:07 +) :
On Tue, Mar 04, 2003 at 02:14:59PM +0100, Bastian Kleineidam wrote:
[...]
# example: current bash version number
BASH_VERSION=`grep-available -P -s Version -n -r '^bash$'`
That will be wrong in the event that somebody has run 'dselect
update' but
On Tue, 04 Mar 2003 14:16:34 +0100 (CET), Jérôme Marant
[EMAIL PROTECTED] wrote:
IIRC you can get it from the postinst parameters. You can have a look
to the policy, in maintainers scripts section.
I thought so as well, but it looks like postinst is only called with
the most recently configured
On Tue, 4 Mar 2003 07:16:11 -0600, Graham Wilson [EMAIL PROTECTED]
wrote:
On Tue, Mar 04, 2003 at 01:41:58PM +0100, Marc Haber wrote:
Parsing /usr/share/doc/$PACKAGE/changelog.gz is out of the question
since /usr/share/doc need not be present, and calling dpkg --list
$PACKAGE and parsing its
On Tue, Mar 04, 2003 at 04:58:32PM +0100, Marc Haber wrote:
On Tue, 4 Mar 2003 10:40:52 -0300, Henrique de Moraes Holschuh
[EMAIL PROTECTED] wrote:
No. Do not skip the proper interface layers. Use dpkg to get that
information.
Calling dpkg is actually the recommended way to do this? Can I
On Tue, Mar 04, 2003 at 05:02:22PM +0100, Marc Haber wrote:
On Tue, 04 Mar 2003 14:16:34 +0100 (CET), J?r?me Marant
[EMAIL PROTECTED] wrote:
IIRC you can get it from the postinst parameters. You can have a look
to the policy, in maintainers scripts section.
I thought so as well, but it
Marc,
Well, I wouldn't have posted without first consulting policy and
developer's reference. Section 6.4 doesn't seem to document any
maintainer script of the package being installed being called with the
new version number as a parameter, so I was actually hoping that dpkg
sends that
Roland Mas wrote:
Colin Watson (2003-03-04 14:06:07 +) :
On Tue, Mar 04, 2003 at 02:14:59PM +0100, Bastian Kleineidam wrote:
How about the following?
BASH_VERSION=$(dpkg -s bash | awk '/^Version:/ { print $2 }')
if [ $(dpkg -s bash | awk '/^Status:/ { print $3 $4 }') == ok installed
]
En réponse à Sven Luther [EMAIL PROTECTED]:
On Tue, Mar 04, 2003 at 04:58:32PM +0100, Marc Haber wrote:
On Tue, 4 Mar 2003 10:40:52 -0300, Henrique de Moraes Holschuh
[EMAIL PROTECTED] wrote:
No. Do not skip the proper interface layers. Use dpkg to get that
information.
Calling
Hello,
On Tue, Mar 04, 2003 at 11:04:29AM +0100, Gergely Nagy wrote:
I am a bit unsure about how to name two upcoming packages of mine, and
wouldn't mind a few suggests :)
So, I have this one package (ccze), which is extensible via plugins,
and I have two, separately maintained, extensions:
Question is, how should I call these packages? ccze-perl and
ccze-slang, or libccze-perl and libccze-slang? Or something completely
different? (If someone says ccze-foo1 and -foo2, I'm going to rip his
hands off :P)
I would suggest ccze-perl and ccze-slang. (Isn't libfoo-perl reserved
Now that my new maintainer application has been approved, I want to
start the process of changing the maintainer field in my packages to use
my @d.o address rather than my personal address.
What is the recommended practice on uploading new versions of packages
just for minor changes like this?
On Tue, Mar 04, 2003 at 02:24:17PM -0600, Kenneth Pronovici wrote:
Now that my new maintainer application has been approved,
congratulations.
What is the recommended practice on uploading new versions of packages
just for minor changes like this? Should I upload new versions of all
of my
Johannes Rohr [EMAIL PROTECTED] writes:
Well, I don't know. Until today I've contacted them three times and
there as been no response except for an acknowledgement of receipt.
Therefore I don't think they'd turn out to be more responsive if I came
begging for money...
It's actually called
On Tuesday 04 March 2003 12:45, Michael Banck wrote:
What is the recommended practice on uploading new versions of packages
just for minor changes like this? Should I upload new versions of all
of my packages, or wait to upload each package until there is a more
significant user-visible
On Tue, 4 Mar 2003 17:34:47 +0100, Simon Richter [EMAIL PROTECTED]
wrote:
Well, I wouldn't have posted without first consulting policy and
developer's reference. Section 6.4 doesn't seem to document any
maintainer script of the package being installed being called with the
new version number
On Tue, 4 Mar 2003 16:41:48 +, Colin Watson [EMAIL PROTECTED]
wrote:
On Tue, Mar 04, 2003 at 05:02:22PM +0100, Marc Haber wrote:
I thought so as well, but it looks like postinst is only called with
the most recently configured version, not with the current version.
Why not just preprocess
On Tue, 04 Mar 2003 17:46:40 +0100 (CET), Jérôme Marant
[EMAIL PROTECTED] wrote:
En réponse à Sven Luther [EMAIL PROTECTED]:
No, it is not. You just need to use the $1 argument to postinst, as
Jerome told you.
IIRC, it is $2.
Policy 6.4 says:
postinst configure most-recently-configured-version
On Tue, 4 Mar 2003 16:41:48 +, Colin Watson [EMAIL PROTECTED]
wrote:
Why not just preprocess the postinst in debian/rules to embed its own
version number directly into it?
Nice idea, thanks!
Is an executeable script (for example an init script) allowed to parse
I don't know if there is a policy on this. I'd recommend switching to
your @d.o address as you're doing regular uploads. If by the time of the
freeze there are still packages left with your old address, an upload
just to fix that is alright. That's just MHO, YMMV.
this is probably the
On Tue, Mar 04, 2003 at 05:01:36PM +0100, Marc Haber wrote:
On Tue, 4 Mar 2003 07:16:11 -0600, Graham Wilson [EMAIL PROTECTED] wrote:
dpkg -l PACKAGE | awk '$2 ~ /PACKAGE/ { print $3 }'
Well, I just said that I consider foo to be bad overkill, and you
proceed to posting foo without any
On Tue, Mar 04, 2003 at 11:52:09PM +0100, Marc Haber wrote:
On Tue, 4 Mar 2003 16:41:48 +, Colin Watson [EMAIL PROTECTED]
wrote:
Why not just preprocess the postinst in debian/rules to embed its own
version number directly into it?
Nice idea, thanks!
Is an executeable script (for
On Fri, Feb 28, 2003 at 11:38:33PM -0500, Joey Hess wrote:
Bastian Kleineidam wrote:
Hmm, dh_make is trying to do a similar approach. Why not use that way?
I like to have the original .tar.gz exactly as I downloaded it. dh_make
unpacks the source and repacks it to a new .orig.tar.gz.
Marc,
You can pull it in using a substvar, I think.
That sounds interesting. Can you elaborate? I know that I can use
substvars in my control file to get automatic dependencies on the libs
I use, but how does that transfer to maintainer scripts?
Never mind, I just looked it up. Substvars
On Tue, Mar 04, 2003 at 01:41:58PM +0100, Marc Haber wrote:
how can a package learn about its current version number?
Parsing /usr/share/doc/$PACKAGE/changelog.gz is out of the question
since /usr/share/doc need not be present, and calling dpkg --list
$PACKAGE and parsing its output looks
57 matches
Mail list logo
