Re: optional building of a package
On Tue, Jun 06, 2006 at 01:04:30AM +0800, Paul Wise wrote:
> On Mon, 2006-06-05 at 09:29 -0300, Nelson A. de Oliveira wrote:
>
> > Just use
> > Depends: probcons (= ${Source-Version})
>
> Please don't use Source-Version - from the dpkg-gencontrol manual:
>
> "The source package version (from the changelog file). This variable is
> now deprecated as its meaning is different from its function, please use
> the source:Version or binary:Version as appropriate."
>
> The reason that this is depreciated is that it was causing packages to
^
This word is deprecated in technical circles for wasting a vowel.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: optional building of a package
Hi!
On 6/5/06, Paul Wise <[EMAIL PROTECTED]> wrote:
On Mon, 2006-06-05 at 09:29 -0300, Nelson A. de Oliveira wrote:
> Just use
> Depends: probcons (= ${Source-Version})
Please don't use Source-Version - from the dpkg-gencontrol manual:
"The source package version (from the changelog file). This variable is
now deprecated as its meaning is different from its function, please use
the source:Version or binary:Version as appropriate."
The reason that this is depreciated is that it was causing packages to
be inappropriately not binNMUable, which is annoying for the release
managers.
Hmm... good to learn this!
Thank you very much!
All the best,
Nelson
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: optional building of a package
On Mon, 2006-06-05 at 09:29 -0300, Nelson A. de Oliveira wrote:
> Just use
> Depends: probcons (= ${Source-Version})
Please don't use Source-Version - from the dpkg-gencontrol manual:
"The source package version (from the changelog file). This variable is
now deprecated as its meaning is different from its function, please use
the source:Version or binary:Version as appropriate."
The reason that this is depreciated is that it was causing packages to
be inappropriately not binNMUable, which is annoying for the release
managers.
--
bye,
pabs
http://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
Re: optional building of a package
Hi!
On 6/5/06, Charles Plessy <[EMAIL PROTECTED]> wrote:
Is there a way to make sure that probcons-extra will depend on the
probcons package with the same version as itself?
Yes.
Just use
Depends: probcons (= ${Source-Version})
inside the probcons-extra section.
Best regards,
Nelson
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: optional building of a package
Le Mon, Jun 05, 2006 at 01:04:37PM +0200, Florent Rougon a écrit : > Charles Plessy <[EMAIL PROTECTED]> wrote: > > > I have made /usr/share/doc/probcons-extra a symlink to > > /usr/share/doc/probcons (probcons-extra depends on probcons). Is it OK > > to do such things? ^^ >this is important > > Yes, this is written in Policy. Dear Florent, Thanks for the hint. As the policy says: "Please note that this does not override the section on changelog files below, so the file /usr/share/package/changelog.Debian.gz must refer to the changelog for the current version of package in question. In practice, this means that the sources of the target and the destination of the symlink must be the same (same source package and version)." Is there a way to make sure that probcons-extra will depend on the probcons package with the same version as itself? Have a nice day, -- Charles -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: optional building of a package
Charles Plessy <[EMAIL PROTECTED]> wrote: > I have made /usr/share/doc/probcons-extra a symlink to > /usr/share/doc/probcons (probcons-extra depends on probcons). Is it OK > to do such things? ^^ this is important Yes, this is written in Policy. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: optional building of a package
Le Sat, Jun 03, 2006 at 05:23:37PM +1000, Matthew Palmer a écrit : > > I am working on packaging probcons, which consists of two main programs > > carrying the core functionalities, and a few other programs with > > ambiguous names (convert, makegunplut, project) which will not be useful > > to the vast majority of users. The upstream author advised me to drop > > them from the package, which I will do. > > Of course, if upstream says "don't include them", they're obviously not > particularly useful, in which case you probably don't need to put them in > the package at all. Dear all, dear Matthew, Thank you for all your answers. I decided to bud off a probcons-extra package, mostly because I wanted to learn how to make more than one binary package frome one source package. I uploaded the resulting package on mentors. http://mentors.debian.net/debian/pool/main/p/probcons/ I have made /usr/share/doc/probcons-extra a symlink to /usr/share/doc/probcons (probcons-extra depends on probcons). Is it OK to do such things? Have a nice day, -- Charles -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: optional building of a package
On Sat, Jun 03, 2006 at 01:46:35PM +0900, Charles Plessy wrote: > I am working on packaging probcons, which consists of two main programs > carrying the core functionalities, and a few other programs with > ambiguous names (convert, makegunplut, project) which will not be useful > to the vast majority of users. The upstream author advised me to drop > them from the package, which I will do. > > However, I was wondering wether it would make sense to provide to the > Debian user a mean to install the extra programs from the Debian sources. > Is there a way to make the source package able to produce a > probcons-extra package, but only optionaly? You *can* create a package optionally (have some sort of build-time option to enable passing the package name to all the relevant debhelper rules), but I'd build the binaries normally, and probably rename them so they're non-conflicting. You *could* put them in /usr/lib/, perhaps, but that just seems... weird. Of course, if upstream says "don't include them", they're obviously not particularly useful, in which case you probably don't need to put them in the package at all. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: optional building of a package
On 6/3/06, Franz Pletz <[EMAIL PROTECTED]> wrote: On Sat, Jun 03, 2006 at 01:46:35PM +0900, Charles Plessy wrote: > ambiguous names (convert, makegunplut, project) which will not be useful Please keep in mind that there's already a convert binary in imagemagick, so you should either not install those to /usr/bin and distribute them for instance under /usr/share or not at all. Hum... shouldn't they be distributed under /usr/lib/packagename? As I know, /usr/share is only for arch independent stuff and convert and other programs are binary files. Best regards, Nelson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: optional building of a package
On Sat, Jun 03, 2006 at 01:46:35PM +0900, Charles Plessy wrote: > ambiguous names (convert, makegunplut, project) which will not be useful Please keep in mind that there's already a convert binary in imagemagick, so you should either not install those to /usr/bin and distribute them for instance under /usr/share or not at all. Cheers, Franz -- Franz Pletz \ Lots of the basis of the open source movement www: http://franz-pletz.org/ \ come from procrastinating students. email: [EMAIL PROTECTED] \ -- Andrew Tridgell signature.asc Description: Digital signature
Re: optional building of a package
Hi! On 6/3/06, Charles Plessy <[EMAIL PROTECTED]> wrote: On the other hand, it could simply build a probcons-extra package by default, with a clear description saying that it is likely that probcons-extra will not be useful to the persons tempted to install it. My opinion is that it's better to do this. Create the package and let the user choose if he finds it useful or not. Someone may think that it's useful, right? (even if someone means just a small number of users) Best regards, Nelson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: optional building of a package
On Sat, 3 Jun 2006, Charles Plessy wrote: However, I was wondering wether it would make sense to provide to the Debian user a mean to install the extra programs from the Debian sources. Is there a way to make the source package able to produce a probcons-extra package, but only optionaly? On the other hand, it could simply build a probcons-extra package by default, with a clear description saying that it is likely that probcons-extra will not be useful to the persons tempted to install it. I think the second approach makes more sense to me as an end-user. As I see it, the Debian Way isn't to have all sorts of USE flags and compile-time options, but instead to provide those options to users of binary packages. -- Asheesh. -- When God created two sexes, he may have been overdoing it. -- Charles Merrill Smith -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
