Re: Need some tips on building Debian packages

[John Pye]

Hi Paul

I have also found the migration from RPM packaging to Debian packaging
to be a hard one (I'm *not* a mentor, BTW). Some of my observations include:

   1. Whereas RPM provides one key tool, 'rpmbuild', Debian packaging
  seems to provide dozens of different tools, not all of which are
  used by all users, with the result that different packagers will
  tell you different packaging techniques that seem to have, at
  times, little or no common elements.
   2. Whereas an RPM can be generated at a minimum with one 'special'
  file (the .spec file) that can basically be typed by hand, Debian
  packages seem to provide half a dozen 'special' files: 'rules',
  'changelog', 'control', man pages, etc etc, many of which are best
  to be auto-generated by scripts, because of their complexity.
   3. For people who are packaging their own code, the 'rpmbuild -ta'
  command is really nice, and makes rapid standalone packaging /so/
  much simpler. This allows you to put your packaging files in with
  your source code, making 'developer's own' binary releases much
  simpler.
   4. RPM's support for multiple platforms/distros/arches is, to me,
  more intuitive. I can write a *single* .spec file that builds
  distinct RPMs for OpenSUSE, Fedora, RHEL and Mandriva, just using
  conditional pre-processor statements. That sort of thing seems, on
  first inspection, to be rather difficult to achieve with Debian.
  Again, this is of value to those developers who are also
  attempting to provide binary packages for their users, especially
  for simple packages that don't have too much distro-specific stuff
  to worry about.


If it's of any interest, I wrote a little Python script that appealed to
my RPM sensibilities, while hopefully producing fully compliant Debian
packages. Any feedback would be welcome; it's still under development.
http://ascendwiki.cheme.cmu.edu/Dtar

Essentially, this script just provides the 'rpmbuild -ta' functionality,
but also allows you to package your 'meta files' in a separate tarball
('debian.tar.gz'). This is reasonably compatible, FWIW, with the way
that the OpenSUSE Build Service allows you to package Debian packages.
You still need to generate all those 'rules', 'changelog', etc, files.

One thing I will say about Debian, though, is that writing the above
'dtar' tool was very easy, because of the excellent Python packages that
are available for parsing the variable Debian packaging metafiles.

Cheers
JP

Paul Johnson wrote:
> Hi I'm new here.
>
> I've been asking around for help on building debian packages.  I've
> been building RPMS for about 1 decade, but never tried to build a
> Debian package.   As preparation, I've read through the New
> Maintainer's Guide and miscellaneous other web pages.   I came in
> through the Ubuntu door.  My friends forwarded some questions to a
> person in your list, who suggested I ask here.
>
> Keep in mind that my background is in RPM building, where the emphasis
> is on distributing "pristine" source code.  I was initially
> shocked/dismayed by the Debian approach because the source code gets
> untarred and fiddled with by the packager.  Some of the example guides
> that people referred me to may have been bad examples--packagers were
> opening the source directory and liberally applying patches and making
> changes, and all of those fiddles were getting wrapped up into the one
> big diff file, making it impossible to figure out who did what.
>
> I eventually found out that these were bad examples.  At the end of
> the day, the recommendation for Debian packaging is essentially the
> same as in RedHat: we are aiming to distribute unchanged source that
> is patched in a clear and orderly way. There's not much information on
> how to manage patches in the Debian New Maintainer's Guide, but in
> section 6.4 it does acknowledge the problem and refers to dpatch.
>
> I keep wondering, "If the goal is to re-distribute 'pristine' source
> code and patches, why doesn't Debian discourage users from untarring
> the sourced code?"Why can't you make it so the debian directory is
> not inside the source tree?  One response I've received is that "we
> are not RedHat, try to get over it."
>
> I wonder how you do your day-to-day work on building debs?  I have
> followed the dh_make approach of opening the source, and dh_make gives
> me template files in  "debian" for  control, rules and such.  I
> understand completely that all these different files are just doing
> the same thing as the one big SPEC file does in an rpm framework.
> After configuring those, I try to do a package build.  While testing
> this out, I realize I've made some mistakes while attempting to revise
> the Makefile to match the packaging requirements.  It appears to me
> that I have to 1) move the debian directory to a safe place, 2) erase
> the code tree, 3) untar a fresh copy, 4) copy the debian directory
> back 

Re: Need some tips on building Debian packages

[S'orlok Reaves]

> > It occurred to me that I could try to work around
> this by using a
> > build directory that is completely outside of the
> source code tree.

Hello,
   My own experience is something like this; by the
way, I am also a newbie to packaging, so this is just
what works for me, not necessarily what's right.

1) I use automake/autoconfig, and I've got it set up
properly. I develop my code using the
config/make/install lifecycle.
2) When I'm ready to distribute, I run "make
distcheck", which gives me a .tar.gz of my source.
3) Next, I unzip this into its own directory, which
gives me a directory with the correct version number
that I can then add the debian/ files to.
4) Now, just use the debian build tools as normal,
specifying the unzipped directory as the current
source to build the diff from, and the zipped file as
the .orig.tar.gz file. 

Again, I want to make it very clear that I'm new to
this process, and that I don't endorse my own method.
I came up with it before I knew what the "-i" switch
does, because I needed to exclude some sources from
the .orig.tar.gz that dpkg-buildpackage automatically
added. As I learn more about dpkg, I'll definitely
toss out my hackneyed way of doing things.

Also, dpkg-buildpackage helped me avoid dealing with a
whole bunch of tools; I found it much easier to get
started using this than to use the individual tools
directly. (Except dh_make; that's quite useful, too.)

-->Seth





  


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

What is the best method to update only some binary packages

[Osamu Aoki]

Hi,

Suppose source foo_1.0.tar.gz produces:
 foo-updated_1.0_all.deb
 foo-static_1.0_all.deb

Then with next source foo_1.1.tar.gz with updated contents will produce
now with normal build script:
 foo-updated_1.1_all.deb  (updated from foo-updated_1.0_all.deb)
 foo-static_1.1_all.deb   (same as foo-static_1.0_all.deb)

Then What is the best way to make update archive to have:
 foo-updated_1.1_all.deb
 foo-static_1.0_all.deb

This way user will not be forced to download same package again.

Any suggestion for debian/rules ?  or pointer to good example.

Osamu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: What is the best method to update only some binary packages

[Neil Williams]

On Thu, 2008-10-02 at 23:35 +0900, Osamu Aoki wrote:
> Hi,
> 
> Suppose source foo_1.0.tar.gz produces:
>  foo-updated_1.0_all.deb
>  foo-static_1.0_all.deb
> 
> Then with next source foo_1.1.tar.gz with updated contents will produce
> now with normal build script:
>  foo-updated_1.1_all.deb  (updated from foo-updated_1.0_all.deb)
>  foo-static_1.1_all.deb   (same as foo-static_1.0_all.deb)
> 
> Then What is the best way to make update archive to have:
>  foo-updated_1.1_all.deb
>  foo-static_1.0_all.deb

Generally, that is not what you actually want to do.

1. The source for 1.0 has probably been removed by the archive software
so distributing 1.0 is now illegal.
2. Keeping the source around is not sensible across 20,000 packages.
3. foo-static_1.0_all.deb will not contain the changelog entry for 1.1
causing differences in the copyright and changelog data across different
installations
4. The dependencies may have changed (at least with respect to Arch:any
packages that use shlibs) which can cause aggravation with transitions.
Even with python etc., where packages themselves can be arch:all, having
old packages around that have not been rebuilt against the latest
interpreter is asking of nasty, unreproducible and incomprehensible bug
reports.

> This way user will not be forced to download same package again.

If you want to minimise the download bandwidth, try using a local mirror
and using rsync. i.e. symlink the old .deb to the new .deb filename,
rsync from the local mirror and then install the modified .deb.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




signature.asc
Description: This is a digitally signed message part

Re: What is the best method to update only some binary packages

[Felipe Sateler]

Osamu Aoki wrote:

> Hi,
> 
> Suppose source foo_1.0.tar.gz produces:
>  foo-updated_1.0_all.deb
>  foo-static_1.0_all.deb
> 
> Then with next source foo_1.1.tar.gz with updated contents will produce
> now with normal build script:
>  foo-updated_1.1_all.deb  (updated from foo-updated_1.0_all.deb)
>  foo-static_1.1_all.deb   (same as foo-static_1.0_all.deb)
> 
> Then What is the best way to make update archive to have:
>  foo-updated_1.1_all.deb
>  foo-static_1.0_all.deb
> 
> This way user will not be forced to download same package again.
> 
> Any suggestion for debian/rules ?  or pointer to good example.

You can't really do this, AFAIK. You can break the source into 2 separate source
packages that each build one package. That way you only update the foo-updated
package.

-- 

  Felipe Sateler


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: What is the best method to update only some binary packages

[Felipe Sateler]

El 02/10/08 12:51 Osamu Aoki escribió:
> On Thu, Oct 02, 2008 at 12:10:16PM -0400, Felipe Sateler wrote:
> > Osamu Aoki wrote:
> > > Any suggestion for debian/rules ?  or pointer to good example.
> >
> > You can't really do this, AFAIK. You can break the source into 2
> > separate source packages that each build one package. That way you
> > only update the foo-updated package.
>
> from maint-guide:
>
> #   dh_gencontrol
> # up to date versions, using the default value of 1.2* in debian/changelog:
> DH_OPTIONS="-p$(name)" dh_gencontrol
> DH_OPTIONS="-p$(name)-fr" dh_gencontrol
> DH_OPTIONS="-p$(name)-ja" dh_gencontrol
> DH_OPTIONS="-p$(name)-pl" dh_gencontrol
> DH_OPTIONS="-p$(name)-it" dh_gencontrol
> DH_OPTIONS="-p$(name)-zh" dh_gencontrol
> DH_OPTIONS="-p$(name)-ko" dh_gencontrol
> DH_OPTIONS="-p$(name)-de" dh_gencontrol
> DH_OPTIONS="-p$(name)-es" dh_gencontrol
> DH_OPTIONS="-p$(name)-pt" dh_gencontrol
> DH_OPTIONS="-p$(name)-ru" dh_gencontrol
> # out of date versions:
> # If no change from old version,
> # upload with the same version to prevent updating.
> #DH_OPTIONS="-p$(name)-XX -u"-v1.X.Y-Z"" dh_gencontrol

Will dak accept such a package? I doubt so.

Saludos,
Felipe Sateler


signature.asc
Description: This is a digitally signed message part.

Re: What is the best method to update only some binary packages

[Osamu Aoki]

Hi,

My question is arch:all (not any)  ... more specifically,
foo-static_1.0_all.deb is documentation package which does not change
document contents from 1.0 to 1.1 transition.

I know there is a way to do it but I am not sure if it is a good and
valid way.  I also was not sure where I have seen it.  I think Josip
used to use this trick for translation packages without updates for
something like doc-debian ... wait that is maint-guide   (I now
maintain).  As I see it there are lines in its debian/rules entry which
seems to have meant to forces specific version using dh_gencontrol.

 * Is this still useful technique?
 * Is this the best method?
 * Does anyone know recent ftp mater behavior on such trick?

Let me reply to you as below

On Thu, Oct 02, 2008 at 04:05:05PM +0100, Neil Williams wrote:
> On Thu, 2008-10-02 at 23:35 +0900, Osamu Aoki wrote:
> > Hi,
> > 
> > Suppose source foo_1.0.tar.gz produces:
> >  foo-updated_1.0_all.deb
> >  foo-static_1.0_all.deb
> > 
> > Then with next source foo_1.1.tar.gz with updated contents will produce
> > now with normal build script:
> >  foo-updated_1.1_all.deb  (updated from foo-updated_1.0_all.deb)
> >  foo-static_1.1_all.deb   (same as foo-static_1.0_all.deb)
> > 
> > Then What is the best way to make update archive to have:
> >  foo-updated_1.1_all.deb
> >  foo-static_1.0_all.deb
> 
> Generally, that is not what you actually want to do.
> 
> 1. The source for 1.0 has probably been removed by the archive software
> so distributing 1.0 is now illegal.

Are you sure?

I think it uploaded with foo_1.0_amd64.changes having something like
both foo-updated_1.1_all.deb and foo-static_1.0_all.deb so archive
software will not remove foo-static_1.0_all.deb.

> 2. Keeping the source around is not sensible across 20,000 packages.

Sure but that is not the issue.

> 3. foo-static_1.0_all.deb will not contain the changelog entry for 1.1
> causing differences in the copyright and changelog data across different
> installations

I vaguely remember that uploading set of binary packages such as these
will not move to pool/ since there is already such package.  At the same
time, foo_1.0_amd64.changes ensures old foo-static_1.0_all.deb to stay
in archive.  

> 4. The dependencies may have changed (at least with respect to Arch:any
> packages that use shlibs) which can cause aggravation with transitions.
> Even with python etc., where packages themselves can be arch:all, having
> old packages around that have not been rebuilt against the latest
> interpreter is asking of nasty, unreproducible and incomprehensible bug
> reports.

Of course that is something packager must pay attention.  But this risk
is manageable for the case discussed.

> > This way user will not be forced to download same package again.
> 
> If you want to minimise the download bandwidth, try using a local mirror
> and using rsync. i.e. symlink the old .deb to the new .deb filename,
> rsync from the local mirror and then install the modified .deb.

I may have confused you.

This way user will not be forced to download another documentation
package in which only the version number is bumped.  That is waiste for
everyone and can not be solved by local mirror nor by local cache
server.

Osamu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: What is the best method to update only some binary packages

[Osamu Aoki]

On Thu, Oct 02, 2008 at 12:10:16PM -0400, Felipe Sateler wrote:
> Osamu Aoki wrote:
> > Any suggestion for debian/rules ?  or pointer to good example.
> 
> You can't really do this, AFAIK. You can break the source into 2
> separate source packages that each build one package. That way you
> only update the foo-updated package.

from maint-guide:

#   dh_gencontrol
# up to date versions, using the default value of 1.2* in debian/changelog:
DH_OPTIONS="-p$(name)" dh_gencontrol
DH_OPTIONS="-p$(name)-fr" dh_gencontrol
DH_OPTIONS="-p$(name)-ja" dh_gencontrol
DH_OPTIONS="-p$(name)-pl" dh_gencontrol
DH_OPTIONS="-p$(name)-it" dh_gencontrol
DH_OPTIONS="-p$(name)-zh" dh_gencontrol
DH_OPTIONS="-p$(name)-ko" dh_gencontrol
DH_OPTIONS="-p$(name)-de" dh_gencontrol
DH_OPTIONS="-p$(name)-es" dh_gencontrol
DH_OPTIONS="-p$(name)-pt" dh_gencontrol
DH_OPTIONS="-p$(name)-ru" dh_gencontrol
# out of date versions:
# If no change from old version,
# upload with the same version to prevent updating.
#DH_OPTIONS="-p$(name)-XX -u"-v1.X.Y-Z"" dh_gencontrol



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: What is the best method to update only some binary packages

[Neil Williams]

On Fri, 3 Oct 2008 01:47:51 +0900
Osamu Aoki <[EMAIL PROTECTED]> wrote:

> I know there is a way to do it 

??

On what basis? Which packages? Are you confusing porter uploads
using dpkg-buildpackage -B ?

> but I am not sure if it is a good and
> valid way.  I also was not sure where I have seen it.  I think Josip
> used to use this trick for translation packages without updates for

This trick should not be necessary (or used) - not with the current
toolset. Translation packages are completely separate and TDebs (which I
am developing within Debian for Squeeze) will use a different method.

> something like doc-debian ... wait that is maint-guide   (I now
> maintain).  As I see it there are lines in its debian/rules entry which
> seems to have meant to forces specific version using dh_gencontrol.

That is not the same thing. It can be used to correct certain errors
but, AFAICT, it is not intended for routine usage.

>  * Is this still useful technique?

Not for you want to do, no. One-off fixes might be necessary but not
for packages discussed on this list.

> > Generally, that is not what you actually want to do.
> > 
> > 1. The source for 1.0 has probably been removed by the archive software
> > so distributing 1.0 is now illegal.
> 
> Are you sure?

Yes. I run several repositories. You are describing a native package in
your example. The .tar.gz will be removed when a new version is
uploaded - the only time it will be retained is if the old version
exists in a different distribution, e.g. testing. As soon as the
package migrates, the source will be removed. The .changes file you
describe will try to correlate the 1.0 package with the 1.1 source (due
to the changes file and .dsc itself being 1.1) which is simply
incorrect.

The problem gets worse with non-native packages when a new upstream
release is made. Keeping the gcc source package around for various
versions according to the state of various packages built from the gcc
source that haven't changed - I can't really see the ftpmasters liking
that idea.

It is also hard to ensure that maintainers correctly synchronise the
packages - you'd need a whole new process to check the content that
would have been included against the content still packaged in the old
version.

I don't see that it is worth investigation at this stage and certainly
not on this list. Take it to debian-devel if you want to start work on
the various fixes and scripts that could be necessary to make it sane.

> I think it uploaded with foo_1.0_amd64.changes having something like
> both foo-updated_1.1_all.deb and foo-static_1.0_all.deb so archive
> software will not remove foo-static_1.0_all.deb.

That is just plain broken.

> > 2. Keeping the source around is not sensible across 20,000 packages.
> 
> Sure but that is not the issue.

Of course it is. The archive managers do not want extra source versions
hanging around and without extra source versions, the archive is
illegal.

> > 3. foo-static_1.0_all.deb will not contain the changelog entry for 1.1
> > causing differences in the copyright and changelog data across different
> > installations
> 
> I vaguely remember that uploading set of binary packages such as these
> will not move to pool/ since there is already such package.  At the same
> time, foo_1.0_amd64.changes ensures old foo-static_1.0_all.deb to stay
> in archive.  

The package will not contain the modified changelog. The changelog was
modified *AFTER* the 1.0 was built and only exists in the 1.1. The
changelog is part of the legal source under some (free) licences.

> > 4. The dependencies may have changed (at least with respect to Arch:any
> > packages that use shlibs) which can cause aggravation with transitions.
> > Even with python etc., where packages themselves can be arch:all, having
> > old packages around that have not been rebuilt against the latest
> > interpreter is asking of nasty, unreproducible and incomprehensible bug
> > reports.
> 
> Of course that is something packager must pay attention.  But this risk
> is manageable for the case discussed.
> 
> > > This way user will not be forced to download same package again.
> > 
> > If you want to minimise the download bandwidth, try using a local mirror
> > and using rsync. i.e. symlink the old .deb to the new .deb filename,
> > rsync from the local mirror and then install the modified .deb.
> 
> I may have confused you.
> 
> This way user will not be forced to download another documentation
> package in which only the version number is bumped.  That is waiste for
> everyone and can not be solved by local mirror nor by local cache
> server.

Of course it can - the local mirror is shared between various users and
those users can use rsync.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgp27OIJEZk2y.pgp
Description: PGP signature

Re: What is the best method to update only some binary packages

[Don Armstrong]

On Thu, 02 Oct 2008, Osamu Aoki wrote:
> This way user will not be forced to download same package again.

Having the same binary version on the same architecture come from two
different source versions is fundamentally broken.

It behavoir is non-defined in the BTS

You also won't satisfy your desired goal, because the metadata in the
packages will most likely differ, and libapt will install the new
package anyway.

The right way to solve this problem is to split the -doc packages out.
 

Don Armstrong

-- 
"For those who understand, no explanation is necessary.
 For those who do not, none is possible."

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Building package,

[Elías A. M.]

Hi,
Somebody  know why when I build the package, show me:
dpkg-shlibdeps: warning: debian/pack/usr/games/pack shouldn't be linked with
libpthread.so.0 (it uses none of its symbols).

and,

dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}

Those two warnings, show me. But the lintian test is ok.

Thanks for advance,

Re: Building package,

[David Paleino]

On Thu, 2 Oct 2008 15:03:40 -0500, Elías A. M. wrote:

> Hi,
> Somebody  know why when I build the package, show me:
> dpkg-shlibdeps: warning: debian/pack/usr/games/pack shouldn't be linked with
> libpthread.so.0 (it uses none of its symbols).

Try passing -Wl,--as-needed into LDFLAGS to the compiler (in debian/rules,
configure target usually). Be warned that this might break your package
unexpectedly!

> dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}

You can safely ignore this warning.

Kindly,
David

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: Building package,

[Luca Bruno]

On Thu, Oct 02, 2008 at 03:03:40PM -0500, =?ISO-8859-1?Q?El=EDas_A._M._ wrote:
> Hi,

Hi I'm not a developer but I try to suggest you.

> Somebody  know why when I build the package, show me:
> dpkg-shlibdeps: warning: debian/pack/usr/games/pack shouldn't be linked with
> libpthread.so.0 (it uses none of its symbols).
>

Your package is linking against libpthread and it might not be used. If your
program uses it, then ignore the warning. If your program doesn't really use
it, add --as-needed in the LDFLAGS in your debian/rules.
 
> and,
> 
> dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
> 
> Those two warnings, show me. But the lintian test is ok.
>

I think you can ignore this one.
 
> Thanks for advance,

You're welcome, I'm at the beggining just like you.

-- 
http://syx.googlecode.com - Smalltalk YX
http://lethalman.blogspot.com - Thoughts about computer technologies
http://www.debian.org - The Universal Operating System


signature.asc
Description: Digital signature

Unheeded warnings from build tools (was: Building package,)

[Ben Finney]

David Paleino <[EMAIL PROTECTED]> writes:

> On Thu, 2 Oct 2008 15:03:40 -0500, Elías A. M. wrote:
> > dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
> 
> You can safely ignore this warning.

Luca Bruno <[EMAIL PROTECTED]> writes:

> On Thu, Oct 02, 2008 at 03:03:40PM -0500, =?ISO-8859-1?Q?El=EDas_A._M._ wrote:
> > dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
> 
> I think you can ignore this one.

I think it'sa bad situation when a build tool emits a warning that is
routinely ignored; it commonly leads to masking real problems.

The correct solution is for the warning to go away. Either this *is*
something that needs attention, or it is not. In the former case, what
is the problem and what is the solution? In the latter case, why is
the warning there at all?

-- 
 \  “Ocean, n. A body of water occupying about two-thirds of a |
  `\ world made for man — who has no gills.” —Ambrose Bierce, _The |
_o__)Devil's Dictionary_, 1906 |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Unheeded warnings from build tools

[Russ Allbery]

Ben Finney <[EMAIL PROTECTED]> writes:

> I think it'sa bad situation when a build tool emits a warning that is
> routinely ignored; it commonly leads to masking real problems.
>
> The correct solution is for the warning to go away. Either this *is*
> something that needs attention, or it is not. In the former case, what
> is the problem and what is the solution? In the latter case, why is the
> warning there at all?

I think the easiest way to make the warning go away would be for debhelper
to always define misc:Depends, possibly to the empty string (#498666 which
is already tagged pending).

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Building package,

[Charles Plessy]

> On Thu, Oct 02, 2008 at 03:03:40PM -0500, =?ISO-8859-1?Q?El=EDas_A._M._ wrote:
> > dpkg-shlibdeps: warning: debian/pack/usr/games/pack shouldn't be linked with
> > libpthread.so.0 (it uses none of its symbols).
 
Le Thu, Oct 02, 2008 at 11:15:20PM +0200, Luca Bruno a écrit :
> Your package is linking against libpthread and it might not be used. If your
> program uses it, then ignore the warning. If your program doesn't really use
> it, add --as-needed in the LDFLAGS in your debian/rules.

Hi all,

Is it the kind of issue that is worth reporting upstream? If yes, could
somebody update http://wiki.debian.org/GettingPackaged (I do not
understand enough the issue for doing it myself). It would then be easy
to inform upstream of the unnecessary links and point at this page for
the explanations.

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Building package,

[Felipe Sateler]

Luca Bruno wrote:

> On Thu, Oct 02, 2008 at 03:03:40PM -0500, =?ISO-8859-1?Q?El=EDas_A._M._ wrote:
>> Hi,
> 
> Hi I'm not a developer but I try to suggest you.
> 
>> Somebody  know why when I build the package, show me:
>> dpkg-shlibdeps: warning: debian/pack/usr/games/pack shouldn't be linked with
>> libpthread.so.0 (it uses none of its symbols).
>>
> 
> Your package is linking against libpthread and it might not be used. If your
> program uses it, then ignore the warning. If your program doesn't really use
> it, add --as-needed in the LDFLAGS in your debian/rules.

When (for some reason) -pthread is passed to gcc, the -Wl,--as-needed flag won't
unlink it (newlines added for clarity):

% gcc -o test test.c
% objdump -p test | grep NEEDED
  NEEDED  libc.so.6

% gcc -pthread -o test test.c
% objdump -p test | grep NEEDED
  NEEDED  libpthread.so.0
  NEEDED  libc.so.6

% gcc -lpthread -o test test.c
% objdump -p test | grep NEEDED
  NEEDED  libpthread.so.0
  NEEDED  libc.so.6

% gcc -Wl,--as-needed -lpthread -o test test.c
% objdump -p test | grep NEEDED
  NEEDED  libc.so.6

% gcc -Wl,--as-needed -pthread -o test test.c
% objdump -p test | grep NEEDED
  NEEDED  libpthread.so.0
  NEEDED  libc.so.6

%


-- 

  Felipe Sateler


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Building package,

[Elías A. M.]

Hi again:
I tried your suggests, but I don't have successful
I put, my debian/rules:
--
include /usr/share/dpatch/dpatch.make
#The upstream source don't include "./configure" rule, only "make"
#LDFLAGS=-Wall -g
#export LDFLAGS

build: build-stamp

build-stamp: patch-stamp
dh_testdir
$(MAKE)
touch $@

clean: unpatch
dh_testdir
dh_testroot
rm -f build-stamp configure-stamp
# Add here commands to clean up after the build process.
$(MAKE) clean
dh_clean

install: build
dh_testdir
dh_testroot
dh_clean -k
dh_installdirs

# Add here commands to install the package into debian/jigzo.
cp $(CURDIR)/jigzo $(CURDIR)/debian/jigzo/usr/games
cp -r font $(CURDIR)/debian/jigzo/usr/share/jigzo
cp -r image $(CURDIR)/debian/jigzo/usr/share/jigzo
cp -r sound $(CURDIR)/debian/jigzo/usr/share/jigzo
cp -r puzzles $(CURDIR)/debian/jigzo/usr/share/jigzo
dh_install
# Build architecture-independent files here.
binary-indep: build install
# We have nothing to do by default.

# Build architecture-dependent files here.
binary-arch: build install
dh_testdir
dh_testroot
dh_installchangelogs
dh_installdocs
dh_desktop
dh_installmenu
dh_installman
dh_link
dh_strip
dh_compress
dh_fixperms
dh_installdeb
dh_shlibdeps
dh_gencontrol
dh_md5sums
dh_builddeb

binary: binary-indep binary-arch
.PHONY: build clean binary-indep binary-arch binary install configure

Sorry, I'm newbie

Thanks for advance

On Thu, Oct 2, 2008 at 3:03 PM, Elías A. M. <[EMAIL PROTECTED]> wrote:

> Hi,
> Somebody  know why when I build the package, show me:
> dpkg-shlibdeps: warning: debian/pack/usr/games/pack shouldn't be linked
> with libpthread.so.0 (it uses none of its symbols).
>
> and,
>
> dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
>
> Those two warnings, show me. But the lintian test is ok.
>
> Thanks for advance,
>
>

Re: Unheeded warnings from build tools (was: Building package,)

[Paul Wise]

On Fri, Oct 3, 2008 at 7:48 AM, Ben Finney <[EMAIL PROTECTED]> wrote:

> The correct solution is for the warning to go away. Either this *is*
> something that needs attention, or it is not. In the former case, what
> is the problem and what is the solution? In the latter case, why is
> the warning there at all?

This won't be an issue for packages using debhelper in the future:

http://bugs.debian.org/498666

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]