Re: Build-Depends :native

[Sven Joachim]

On 2019-06-22 12:20 +0200, Jörg Frings-Fürst wrote:

> Hello,
>
> can someone please tell me a source about the meaning of :native in the
> Build-Depends?

The architecture you are building on, see deb-src-control(5):

,
| An architecture qualifier name can be a real Debian architecture name
| (since dpkg 1.16.5), any (since dpkg 1.16.2) or native (since dpkg
| 1.16.5).  If omitted, the default for Build-Depends fields is the
| current host architecture, the default for Build-Conflicts fields is
| any.  A real Debian architecture name will match exactly that
| architecture for that package name, any will match any architecture for
| that package name if the package is marked with Multi-Arch: allowed, and
| native will match the current build architecture if the package is not
| marked with Multi-Arch: foreign.
`

E.g. if your current architecture is amd64, and you are building for
armhf, "Build-Depends: python3:native" means you have to install
python3:amd64 and not python3:armhf.

Cheers,
   Sven

Re: Build-Depends for a Python wrapper

[Matthew Fernandez]

> On Dec 25, 2018, at 02:41, Geert Stappers  wrote:
> 
> On Mon, Dec 24, 2018 at 06:09:04PM -0800, Matthew Fernandez wrote:
>> Hello Debian Mentors,
>> 
>> I???m preparing to request a piece of software I maintain be made
>> available on Debian and have been doing my homework trying to package
>> it correctly.
>> 
>> It???s a C++ binary, but comes with a Python wrapper for invoking it
>> [0]. This script should run with either Python 2 or Python 3 and
>> requires no non-standard modules, but I???m having trouble getting
>> lintian to approve of it.
>> 
>> In trying to pacify its warnings, I seem to keep causing new
>> ones. The latest is missing-build-dependency-for-dh-addon which seemed
>> straightforward, but I???m having trouble resolving it.
>> 
>> Is it possible I???m just going about this the wrong way? You can see my
>> current fumblings around in the dark for the light switch at [1]. I have
>> not packaged something for Debian before, so apologies if this question
>> is answered elsewhere and my search skills failed me. If you have any
>> time to point me in the right direction, I would be very grateful.
>> 
>> Thanks, Matthew
>> 
>> [0]: 
>> https://github.com/Smattr/rumur/blob/packaging/debian/rumur/src/rumur-run
>> [1]: https://github.com/Smattr/rumur/blob/packaging/debian/debian/control
> 
> Multiline Build-Depends
> 
> --- a/debian/control
> +++ b/debian/control
> @@ -2,7 +2,13 @@ Source: rumur
> Section: devel
> Priority: optional
> Maintainer: Matthew Fernandez 
> -Build-Depends: debhelper (>= 10), bison (>= 3.0), cmake (>= 3.1), dh-python, 
> flex (>= 2.5.35), libgmp-dev, python (>= 2.7)
> +Build-Depends: debhelper (>= 10)
> +  , bison (>= 3.0)
> +  , cmake (>= 3.1)
> +  , dh-python
> +  , flex (>= 2.5.35)
> +  , libgmp-dev
> +  , python (>= 2.7)
> Standards-Version: 3.9.8
> Homepage: https://github.com/Smattr/rumur
> Vcs-Git: https://github.com/Smattr/rumur.git
> 
> 
> 
> 
> | 
> | $ lintian --info ../rumur_2018.12.20_amd64.changes 
> | E: rumur source: missing-build-dependency-for-dh-addon python3 => 
> python3:any | python3-all:any | python3-dev:any | python3-all-dev:any
> | N: 
> | N:The source package appears to be using a dh addon but doesn't build
> | N:depend on the package that actually provides it. If it uses it, it 
> must
> | N:build depend on it.
> | N:
> | N:Severity: important, Certainty: possible
> | N:
> | N:Check: debhelper, Type: source
> | N: 
> | 
> 
> 
> --- a/debian/control
> +++ b/debian/control
> @@ -9,6 +9,7 @@ Build-Depends: debhelper (>= 10)
>   , flex (>= 2.5.35)
>   , libgmp-dev
>   , python (>= 2.7)
> +  , python3
> Standards-Version: 3.9.8
> Homepage: https://github.com/Smattr/rumur
> Vcs-Git: https://github.com/Smattr/rumur.git
> 
> 
> 
> Find attached two patches that you may apply with `git am  *.patch`
> 
> 
> Groeten
> Geert Stappers

Ah, perfect! It did not occur to me that python and python3 are separate 
packages, and then I misinterpreted lintian’s output. Much appreciated, Geert!

Re: Build-Depends for a Python wrapper

[Geert Stappers]

On Mon, Dec 24, 2018 at 06:09:04PM -0800, Matthew Fernandez wrote:
> Hello Debian Mentors,
>
> I???m preparing to request a piece of software I maintain be made
> available on Debian and have been doing my homework trying to package
> it correctly.
>
> It???s a C++ binary, but comes with a Python wrapper for invoking it
> [0]. This script should run with either Python 2 or Python 3 and
> requires no non-standard modules, but I???m having trouble getting
> lintian to approve of it.
>
> In trying to pacify its warnings, I seem to keep causing new
> ones. The latest is missing-build-dependency-for-dh-addon which seemed
> straightforward, but I???m having trouble resolving it.
>
> Is it possible I???m just going about this the wrong way? You can see my
> current fumblings around in the dark for the light switch at [1]. I have
> not packaged something for Debian before, so apologies if this question
> is answered elsewhere and my search skills failed me. If you have any
> time to point me in the right direction, I would be very grateful.
>
> Thanks, Matthew
>
> [0]: https://github.com/Smattr/rumur/blob/packaging/debian/rumur/src/rumur-run
> [1]: https://github.com/Smattr/rumur/blob/packaging/debian/debian/control

Multiline Build-Depends

--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,13 @@ Source: rumur
 Section: devel
 Priority: optional
 Maintainer: Matthew Fernandez 
-Build-Depends: debhelper (>= 10), bison (>= 3.0), cmake (>= 3.1), dh-python, 
flex (>= 2.5.35), libgmp-dev, python (>= 2.7)
+Build-Depends: debhelper (>= 10)
+  , bison (>= 3.0)
+  , cmake (>= 3.1)
+  , dh-python
+  , flex (>= 2.5.35)
+  , libgmp-dev
+  , python (>= 2.7)
 Standards-Version: 3.9.8
 Homepage: https://github.com/Smattr/rumur
 Vcs-Git: https://github.com/Smattr/rumur.git
 



| 
| $ lintian --info ../rumur_2018.12.20_amd64.changes 
| E: rumur source: missing-build-dependency-for-dh-addon python3 => python3:any 
| python3-all:any | python3-dev:any | python3-all-dev:any
| N: 
| N:The source package appears to be using a dh addon but doesn't build
| N:depend on the package that actually provides it. If it uses it, it must
| N:build depend on it.
| N:
| N:Severity: important, Certainty: possible
| N:
| N:Check: debhelper, Type: source
| N: 
| 


--- a/debian/control
+++ b/debian/control
@@ -9,6 +9,7 @@ Build-Depends: debhelper (>= 10)
   , flex (>= 2.5.35)
   , libgmp-dev
   , python (>= 2.7)
+  , python3
 Standards-Version: 3.9.8
 Homepage: https://github.com/Smattr/rumur
 Vcs-Git: https://github.com/Smattr/rumur.git



Find attached two patches that you may apply with `git am  *.patch`


Groeten
Geert Stappers
-- 
Leven en laten leven
From 5e60bee663a51ff6c0a7145ba08855b7c8753c64 Mon Sep 17 00:00:00 2001
From: Geert Stappers 
Date: Tue, 25 Dec 2018 11:15:37 +0100
Subject: [PATCH 1/2] Multilined the Build-Depends

To make further updates on build dependencies more diff friendly.
---
 debian/control | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 550ce5b..d86c6bc 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,13 @@ Source: rumur
 Section: devel
 Priority: optional
 Maintainer: Matthew Fernandez 
-Build-Depends: debhelper (>= 10), bison (>= 3.0), cmake (>= 3.1), dh-python, flex (>= 2.5.35), libgmp-dev, python (>= 2.7)
+Build-Depends: debhelper (>= 10)
+  , bison (>= 3.0)
+  , cmake (>= 3.1)
+  , dh-python
+  , flex (>= 2.5.35)
+  , libgmp-dev
+  , python (>= 2.7)
 Standards-Version: 3.9.8
 Homepage: https://github.com/Smattr/rumur
 Vcs-Git: https://github.com/Smattr/rumur.git
-- 
2.20.1

From b1b7cb644a625bc20579cf83cb8da7f1a77c173e Mon Sep 17 00:00:00 2001
From: Geert Stappers 
Date: Tue, 25 Dec 2018 11:29:23 +0100
Subject: [PATCH 2/2] Also build depend on python3

---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index d86c6bc..815075e 100644
--- a/debian/control
+++ b/debian/control
@@ -9,6 +9,7 @@ Build-Depends: debhelper (>= 10)
   , flex (>= 2.5.35)
   , libgmp-dev
   , python (>= 2.7)
+  , python3
 Standards-Version: 3.9.8
 Homepage: https://github.com/Smattr/rumur
 Vcs-Git: https://github.com/Smattr/rumur.git
-- 
2.20.1



signature.asc
Description: PGP signature

Re: build-depends for different distro releases

[Mattia Rizzolo]

On Fri, 2 Mar 2018, 10:54 p.m. Daniel Sperka,  wrote:

>It seems that under stretch, libvtk5 has been replaced by libvtk6, and
> libpng12 by libpng16.
>

This is the *very* reason for which -dev packages shouldn't contain the
soversion...


Given that you are using cowbuilder, which respects the alternative
build-dependencies, just put the all separated by |, in the meantime hoping
they will become unversioned in the future.

Re: build-depends for different distro releases

[Dan Kegel]

I put 'em all on separate lines so I can add comments;
my control tends to look like this for packages that build on multiple
versions of ubuntu:

Build-Depends: debhelper (>= 7),
# libpng12-dev for ubuntu 16.04, libpng-dev for ubuntu 17.10 and up
   libpng12-dev | libpng-dev,
   libvtk6-dev | libvtk5-dev,
...

It's a fragile approach, but works well enough here.  Sometimes I have
to add version
specifiers or depend on proxy packages just to test which platform.  Ugh.
- Dan

On Fri, Mar 2, 2018 at 1:53 PM, Daniel Sperka  wrote:
>I'm updating the packaging for a software package for debian and ubuntu
> (via neurodebian). The src package will build (using cowbuilder) under
> ubuntu xenial and debian jessie.
>
>Under stretch, the build fails while updating build-deps:
>
>  pbuilder-satisfydepends-dummy :
>  Depends: libvtk5-dev which is a virtual package and is not provided by
> any available package
>  Depends: libpng12-dev which is a virtual package and is not provided by
> any available package
>
>It seems that under stretch, libvtk5 has been replaced by libvtk6, and
> libpng12 by libpng16.
>
>How can I express this in a single control file? In other words, my
> control file has the following (which works under debian/jessie and
> ubuntu/xenial):
>
> Under xenial/jessie the following is in debian/control:
>
> Build-Depends: debhelper (>= 5), libqt4-dev (>= 4.3), libqt4-opengl-dev |
> libqt4-dev (<< 4.4.0), libqwt5-qt4-dev, libvtk5-dev, libminc-dev,
> libqtassistantclient-dev, libpng12-dev, cmake
>
> It seems that I need to have this line be different under debian/stretch:
>
> Under xenial/jessie the following is in debian/control:
>
> Build-Depends: debhelper (>= 5), libqt4-dev (>= 4.3), libqt4-opengl-dev |
> libqt4-dev (<< 4.4.0), libqwt5-qt4-dev, libvtk6-dev, libminc-dev,
> libqtassistantclient-dev, libpng16-dev, cmake
>
>
> Dan
>
>
>
>
>
> --
> Daniel J. Sperka, Ph. D.
> UC Davis Center for Neuroscience

Re: build-depends on a _source_ package ?

[Benoît Rouits]

Thank you Christian for your clear explanation.
I think i only need the headers files, but i will check
this before to file a bug to the qtcreator package, so.

Thankfully,
 Benoît

Le 13/06/2017 à 08:54, Christian Seiler a écrit :

Hi,

On 06/12/2017 11:05 PM, Benoît Rouits wrote:

Is there a solution ? Should i file a bug on WNPP to ask for a
qtcreator-dev package in order to have qtcreator source installed in
/usr/src ?


Do you need the entire source of Qt Creator or just some header files?

In either case, you can only build-depend on binary packages, so that
you will need to ask the Qt Creator people to provide an additional
package for you.

If you only need header files, you should ask them to provide a
-dev package with the headers (and potentially .so libraries). If you
need the entire source tree, then you should ask them to provide a
-source package (see e.g. gcc-6-source, glibc-source, linux-source for
examples of this already in the archive) that puts the entire source
tree into /usr/src.

Note that you shouldn't open a bug on WNPP, but rather a bug on the
qtcreator package itself, severity wishlist, requesting this.

Hope that helps.

Regards,
Christian

Re: build-depends on a _source_ package ?

[Christian Seiler]

Hi,

On 06/12/2017 11:05 PM, Benoît Rouits wrote:
> Is there a solution ? Should i file a bug on WNPP to ask for a
> qtcreator-dev package in order to have qtcreator source installed in
> /usr/src ?

Do you need the entire source of Qt Creator or just some header files?

In either case, you can only build-depend on binary packages, so that
you will need to ask the Qt Creator people to provide an additional
package for you.

If you only need header files, you should ask them to provide a
-dev package with the headers (and potentially .so libraries). If you
need the entire source tree, then you should ask them to provide a
-source package (see e.g. gcc-6-source, glibc-source, linux-source for
examples of this already in the archive) that puts the entire source
tree into /usr/src.

Note that you shouldn't open a bug on WNPP, but rather a bug on the
qtcreator package itself, severity wishlist, requesting this.

Hope that helps.

Regards,
Christian

Re: Build-Depends issue between matplotlib and basemap on anything but amd64

[Sandro Tosi]

work is already in progress, no need to prod or write stuff like
"Don't do that." is not helping anyone

On Fri, Jan 20, 2017 at 3:31 PM, Andreas Tille  wrote:
> [Sandro Tosi  in CC]
>
> On Fri, Jan 20, 2017 at 11:05:44PM +0500, Andrey Rahmatullin wrote:
>> On Fri, Jan 20, 2017 at 05:53:04PM +0100, Andreas Tille wrote:
>> > matplotlib build-depends on:
>> > - python3-mpltoolkits.basemap:arm64
>> > python3-mpltoolkits.basemap depends on:
>> > - python3-matplotlib:arm64
>> > python3-matplotlib depends on:
>> > - python-matplotlib-data:arm64 (>= 2.0.0~rc2-1)
>> > matplotlib build-depends on:
>> > - python3-mpltoolkits.basemap:arm64
>> > python3-mpltoolkits.basemap depends on:
>> > - python3-matplotlib:arm64
>> > python-matplotlib-data conflicts with:
>> > - python3-matplotlib:arm64 (< 2.0.0)
>> So it looks like matplotlib transitively B-D on itself. And because the
>> maintainer uploaded the arch:all and arch:amd64 packages directly, no
>> architectures except amd64 have the same version of arch:all and arch:!all
>> subpackages.
>> Don't do that.
>
> Can this be fixed please?
>
> Thanks
>
>   Andreas.
>
> --
> http://fam-tille.de



-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Re: Build-Depends issue between matplotlib and basemap on anything but amd64

[Andreas Tille]

[Sandro Tosi  in CC]

On Fri, Jan 20, 2017 at 11:05:44PM +0500, Andrey Rahmatullin wrote:
> On Fri, Jan 20, 2017 at 05:53:04PM +0100, Andreas Tille wrote:
> > matplotlib build-depends on:
> > - python3-mpltoolkits.basemap:arm64
> > python3-mpltoolkits.basemap depends on:
> > - python3-matplotlib:arm64
> > python3-matplotlib depends on:
> > - python-matplotlib-data:arm64 (>= 2.0.0~rc2-1)
> > matplotlib build-depends on:
> > - python3-mpltoolkits.basemap:arm64
> > python3-mpltoolkits.basemap depends on:
> > - python3-matplotlib:arm64
> > python-matplotlib-data conflicts with:
> > - python3-matplotlib:arm64 (< 2.0.0)
> So it looks like matplotlib transitively B-D on itself. And because the
> maintainer uploaded the arch:all and arch:amd64 packages directly, no
> architectures except amd64 have the same version of arch:all and arch:!all
> subpackages.
> Don't do that.

Can this be fixed please?

Thanks

  Andreas.

-- 
http://fam-tille.de

Re: Build-Depends issue between matplotlib and basemap on anything but amd64

[Andrey Rahmatullin]

On Fri, Jan 20, 2017 at 05:53:04PM +0100, Andreas Tille wrote:
> matplotlib build-depends on:
> - python3-mpltoolkits.basemap:arm64
> python3-mpltoolkits.basemap depends on:
> - python3-matplotlib:arm64
> python3-matplotlib depends on:
> - python-matplotlib-data:arm64 (>= 2.0.0~rc2-1)
> matplotlib build-depends on:
> - python3-mpltoolkits.basemap:arm64
> python3-mpltoolkits.basemap depends on:
> - python3-matplotlib:arm64
> python-matplotlib-data conflicts with:
> - python3-matplotlib:arm64 (< 2.0.0)
So it looks like matplotlib transitively B-D on itself. And because the
maintainer uploaded the arch:all and arch:amd64 packages directly, no
architectures except amd64 have the same version of arch:all and arch:!all
subpackages.
Don't do that.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Build-Depends vs Depends

[Taylor Kline]

On Jan 3, 2017 9:33 PM, "Paul Wise"  wrote:

On Wed, Jan 4, 2017 at 1:52 AM, Taylor Kline wrote:

> Thanks, that does help a lot, and it helped me to realize that the
packages
> are built on the Debian machines and sent to users already built, so
there's
> no need for the users to install the Build-Depends, right?

Right, except users might want to build packages themselves, in that
case they would have to install the Build-Depends on the machine or
chroot where they are doing the building. There are several tools to
setup an isolated environment and install build-depends automatically.

https://wiki.debian.org/sbuild
https://wiki.debian.org/pbuilder
https://wiki.debian.org/cowbuilder
https://wiki.debian.org/qemubuilder
https://packages.debian.org/whalebuilder

There are a few reasons users might want to build packages:

Customising the packages for their needs.

Rebuilding packages against newer versions of dependencies.

Rebuilding packages for older Debian releases.

Verifying that the source corresponds to the binaries:

https://wiki.debian.org/ReproducibleBuilds

--
bye,
pabs

https://wiki.debian.org/PaulWise


Extremely helpful, Paul, thanks so much for clearing that up 

Re: Build-Depends vs Depends

[Paul Wise]

On Wed, Jan 4, 2017 at 1:52 AM, Taylor Kline wrote:

> Thanks, that does help a lot, and it helped me to realize that the packages
> are built on the Debian machines and sent to users already built, so there's
> no need for the users to install the Build-Depends, right?

Right, except users might want to build packages themselves, in that
case they would have to install the Build-Depends on the machine or
chroot where they are doing the building. There are several tools to
setup an isolated environment and install build-depends automatically.

https://wiki.debian.org/sbuild
https://wiki.debian.org/pbuilder
https://wiki.debian.org/cowbuilder
https://wiki.debian.org/qemubuilder
https://packages.debian.org/whalebuilder

There are a few reasons users might want to build packages:

Customising the packages for their needs.

Rebuilding packages against newer versions of dependencies.

Rebuilding packages for older Debian releases.

Verifying that the source corresponds to the binaries:

https://wiki.debian.org/ReproducibleBuilds

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Build-Depends vs Depends

[Andrey Rahmatullin]

On Tue, Jan 03, 2017 at 12:52:26PM -0500, Taylor Kline wrote:
> Thanks, that does help a lot, and it helped me to realize that the packages
> are built on the Debian machines and sent to users already built, so
> there's no need for the users to install the Build-Depends, right?
Right.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Build-Depends vs Depends

[Taylor Kline]

On Jan 2, 2017 4:56 PM, "Octavio Alvarez"  wrote:

If you are using "apt install" then the packages under Build-Depends are
not installed at all, only those under Depends, and, because they are
needed for the program to work, those are not uninstalled after
installation.

If you are using "apt build-dep" then you are specifically requesting
APT to install packages lised under Build-Depends.

Hope this clarifies everything.

Best regards.


Thanks, that does help a lot, and it helped me to realize that the packages
are built on the Debian machines and sent to users already built, so
there's no need for the users to install the Build-Depends, right?

Re: Build-Depends vs Depends

[Taylor Kline]

On Jan 2, 2017 10:06 PM, "Paul Wise"  wrote:

You might be interested in looking at some of these diagrams to
discover more about how Debian works:

https://wiki.debian.org/Diagrams

You can look up any confusing jargon you find in this glossary:

https://wiki.debian.org/Glossary

--
bye,
pabs

https://wiki.debian.org/PaulWise


Very cool, thanks!

Re: Build-Depends vs Depends

[Paul Wise]

On Fri, Dec 30, 2016 at 12:31 PM, Taylor Kline wrote:

> What is the difference? How are they treated differently during the
> apt installation process? Thanks :)

You might be interested in looking at some of these diagrams to
discover more about how Debian works:

https://wiki.debian.org/Diagrams

You can look up any confusing jargon you find in this glossary:

https://wiki.debian.org/Glossary

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Build-Depends vs Depends

[Octavio Alvarez]

On 01/02/2017 06:06 AM, Taylor Kline wrote:
> Thank you, Octavio. Does this mean apt will temporarily install
> the Build-Depends packages and remove them after the installation
> completes?

If you are using "apt install" then the packages under Build-Depends are
not installed at all, only those under Depends, and, because they are
needed for the program to work, those are not uninstalled after
installation.

If you are using "apt build-dep" then you are specifically requesting
APT to install packages lised under Build-Depends.

Hope this clarifies everything.

Best regards.

Re: Build-Depends vs Depends

[Ben Finney]

Taylor Kline  writes:

> Thank you, Octavio. Does this mean apt

You mean ‘dpkg’.

APT is a tool to fetch packages and to make requests to ‘dpkg’. It is
‘dpkg’'s job to do the actual install/remove of each individual package.

> will temporarily install the Build-Depends packages and remove them
> after the installation completes?

No.

The purpose of the build process is to generate a product that is ready
to install. The build dependencies are not needed after the build is
complete.

-- 
 \   “Pinky, are you pondering what I'm pondering?” “Well, I think |
  `\  so, Brain, but pantyhose are so uncomfortable in the |
_o__)  summertime.” —_Pinky and The Brain_ |
Ben Finney

Re: Build-Depends vs Depends

[Andrey Rahmatullin]

On Mon, Jan 02, 2017 at 09:06:10AM -0500, Taylor Kline wrote:
> Thank you, Octavio. Does this mean apt will temporarily install the
> Build-Depends
> packages and remove them after the installation completes?
apt doesn't build the package during install. Packages that you install
are already built.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Build-Depends vs Depends

[Taylor Kline]

Thank you, Octavio. Does this mean apt will temporarily install the
Build-Depends
packages and remove them after the installation completes?

Re: Build-Depends vs Depends

[Octavio Alvarez]

On 01/01/2017 04:07 PM, Ben Finney wrote:
> Taylor Kline  writes:
> 
>> What is the difference [between the “Build-Depends” field and the
>> “Depends” field]?
> 
> The difference is precisely that between building the package from
> source, versus using the package installed.

For example, a compiler is needed during build time, but it's not needed
to run the program so it would qualify for Build-Depends but not
for Depends.

Build-Depends is used during "apt build-dep" (used for compilation and
building the package) and Depends is used during "apt install".

Best regards.


-- 
Octavio.

Re: Build-Depends vs Depends

[Ben Finney]

Taylor Kline  writes:

> What is the difference [between the “Build-Depends” field and the
> “Depends” field]?

The difference is precisely that between building the package from
source, versus using the package installed.

The “Build-Depends” and “Build-Depends-Indep” fields appear only in the
source package stanza.

The “Depends” field appears only in a binary package stanza.

See Debian Polcy §5.2 for a summary, and §5 generally for a description
of what these fields mean.

> How are they treated differently during the apt installation process?

The installation process (the ‘dpkg’ tool does the actual installation
of an individual package) cares only about “Depends”, the declaration of
what other packages must be installed for this one to work.

The package build servers care about “Build-Depends” and
“Build-Depends-Indep”, because the job they're doing is not to use the
package but to build it from source.

-- 
 \ “Computers are useless. They can only give you answers.” —Pablo |
  `\   Picasso |
_o__)  |
Ben Finney

Re: Build-Depends vs Depends

[Narcis Garcia]

Build-Depends should not make any effect during package installation
process, because it's a dependency only for package-building process.



__
I'm using this express-made address because personal addresses aren't
masked enough at lists.debian.org archives.
El 30/12/16 a les 05:31, Taylor Kline ha escrit:
> What is the difference? How are they treated differently during the
> apt installation process? Thanks :)
> 

Re: Build-Depends vs Depends

[Harlan Lieberman-Berg]

Taylor Kline  writes:
> What is the difference? How are they treated differently during the
> apt installation process? Thanks :)

Build-Depends is used only during build-time.  (Usually on the buildds,
though it can be on developer's computers as well.)

Depends, on the other hand, are packages that are required for the
package to /run/, and must be installed on the users' machines.

For certain packages that are interpreted, rather than compiled, these
are frequently the same list. (Think: python packages that don't have C
extensions).

Hope that makes sense!

Sincerely,
-- 
Harlan Lieberman-Berg
~hlieberman

Re: Build-Depends on source itself [libgap-sage]

[Bill Allombert]

On Wed, Nov 02, 2016 at 12:11:37PM +0800, Paul Wise wrote:
> On Wed, Nov 2, 2016 at 11:22 AM, Jerome BENOIT wrote:
> 
> > Let give a try. I am dealing with the libgap-sage package [1].
> 
> Thanks for the extensive details.
> 
> > To begin with, GAP is a Computer Algebra System (CAS).
> > From an upstream point of view, libgap is not part of GAP itself.
> > libgap is rather a library wrapper for gap meant to get a better
> > access to the GAP kernel and to be used within Sage, which is a kind
> > a umbrella for multiple CAS (GAP, Singular, and a myriad of
> > scientific oriented software packages).
> > Note that, for now at least, GAP itself does not furnish any library; hence 
> > libgap.
> 
> The libgap project seems like a workaround for this bug in GAP?

This is not a bug in GAP. GAP has its own language and does not
provide a C interface. It also uses its own memory manager which is
not compatible with malloc.

Designing a library implies defining an API and an ABI, something that
has not been formalized for libgap.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Re: Build-Depends on source itself [libgap-sage]

[Bill Allombert]

On Wed, Nov 02, 2016 at 03:22:41AM +, Jerome BENOIT wrote:
> Hello,
> 
> > On Tue, Nov 1, 2016 at 12:43 PM, Jerome BENOIT wrote:
> >
> >> for one of my package, libgap-sage [1], the source material used for build
> >> is in fact seded meterial from an other package, gap: grossely the sed 
> >> process
> >> is the main part of libgap package: is there a standard way to use the 
> >> Debian
> >> source package of gap inside my own package libgap-sage ?
> >> Any hint or example is welcome.

Hello Jérome,
I was requested by Felix Salfelder to build gap-dev object files with
-fPIC for this purpose.
Instead of using sed, Sage should use a linker script, this would be
much cleaner.

gap (4r6p5-3) unstable; urgency=low

  * debian/rules:
   - build gap-dev object files with -fPIC to be compatible with use in
 shared libraries.

 -- Bill Allombert   Thu, 19 Sep 2013 15:00:06 +0200

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Re: Build-Depends on source itself [libgap-sage]

[Jerome BENOIT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Thanks for your prompt reply.

On 02/11/16 04:11, Paul Wise wrote:
> On Wed, Nov 2, 2016 at 11:22 AM, Jerome BENOIT wrote:
> 
>> Let give a try. I am dealing with the libgap-sage package [1].
> 
> Thanks for the extensive details.


You are welcome. 
> 
>> To begin with, GAP is a Computer Algebra System (CAS).
>> From an upstream point of view, libgap is not part of GAP itself.
>> libgap is rather a library wrapper for gap meant to get a better
>> access to the GAP kernel and to be used within Sage, which is a kind
>> a umbrella for multiple CAS (GAP, Singular, and a myriad of scientific 
>> oriented software packages).
>> Note that, for now at least, GAP itself does not furnish any library; hence 
>> libgap.
> 
> The libgap project seems like a workaround for this bug in GAP?

Indeed.

> 
>> Basically libgap adds a prefix to the GAP functions and variables,
>> and gather them in a library. We must have in mind the following points:
>> 1] The libgap source ball provides the modified source files with some delay
>> (current modified gap version in libgap is 4.8.3 while the current gap 
>> version is 4.8.5 ,
>> this version being the one in Stretch. In any case, the copyright headers of 
>> the source files
>> are not modified, so they cannot be packaged for copyright reasons.
> 
> That seems like a very suboptimal way to do it.

I guess that everybody is agree here.

> 
>> 2] The scripts that modify the original GAP source files is not distributed 
>> within
>> the libgap upstream source ball, but it is available via the libgap git 
>> repository [2] at Bitbucket
>> along some documentation for generating our own modified GAP source code. 
>> The current Debian source ball
>> for libgap is the git repository material (which unmodified contains but 
>> obsolete GAP material, version 4.8.3).
> 
> Ok, I'm glad this is not a DFSG violation. It could easily have been one.

I took care about this part of the story.

> 
>> 3] The libgap Debian package must be synchronized with the GAP Debian 
>> package, so modifying the (potentially)
>> patched GAP src/ is certainly not only a good idea but also a factor of 
>> stability and good maintenance.
> 
> Agreed.
> 
>> 4] Just the material in the subfolder src/ within the GAP source ball is 
>> needed, that is to say, not the all
>> source ball.
> 
> Makes sense.
> 
>> 5] We want a long term solution to ease the maintenance of Sage[Math] and 
>> its friends.
> 
> It seems clear to me that the only sane long-term solution is for GAP
> upstream to add a proper shared library.

Absolutely agree. My understanding is that the GAP upstream team is working on 
it.
But GAP is an heavy machinery, and  it might be not one of the top priorities.


 Has this been discussed with
> them at all?

I bet we can find long discussion about on the internet.

 Until GAP upstream are willing to do this,

Let focus on this part.


 I suggest one
> of the following:
> 
> Drop the libgap-sage source package entirely and add a secondary
> tarball to the Debian GAP source package containing only the libgap
> scripts and have the Debian build process for GAP use those scripts to
> create libgap-sage dev and lib binary packages. dpkg-source format v3
> can have multiple tarballs, which makes this doable sanely.
>

Keeping the `intersection' with the GAP debian package minimal is also a factor.

 
> OR
> 
> Get the GAP sources removed from the Bitbucket repository.
> 
> Have the build scripts in the libgap Bitbucket repository:
> 
> 1. require info on which source tree to copy or which version to download
> 2. copy that source tree or download that version
> 3. modify the local copy using the scripts as per normal
> 4. build the scripts as per normal
> 
> There might need to be some checking of the copied source tree to make
> sure the scripts still support it.

The current scheme of the libgap-sage package tends to this solution:
the first priority was to bring libga[-sage] to Debian.


> 
> Create a gap-libgap-sage-source (or similar) package from the GAP
> Debian package, containing the GAP src/ directory somewhere under
> /usr/src.
> 
> Have the libgap-sage package build-depend on gap-libgap-sage-source
> and point the libgap scripts at the GAP src/ directory under /usr/src.
> 
> Make sure that the libgap-sage package is binNMUed or rebuilt after
> every gap upload. I expect the script will need to change reasonably
> often due to changes in GAP though.

This is what I had in mind after reading your previous emails and the one of 
Den.

@Bill :
Which solution would you like to favour ?

Personally I prefer the second solution as it treats the GAP material as raw 
material
and that it puts a clear line between GAP and Sage as concerns Debian 
maintenance.

Can I start to write patch against the GAP debian/ material ?

Thanks,
Jerome

> 

- -- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net

Re: Build-Depends on source itself [libgap-sage]

[Paul Wise]

On Wed, Nov 2, 2016 at 11:22 AM, Jerome BENOIT wrote:

> 2] The scripts that modify the original GAP source files is not distributed 
> within
> the libgap upstream source ball, but it is available via the libgap git 
> repository [2] at Bitbucket
> along some documentation for generating our own modified GAP source code. The 
> current Debian source ball
> for libgap is the git repository material (which unmodified contains but 
> obsolete GAP material, version 4.8.3).

One thing I just noticed: Please get libgap upstream to use the Python
subprocess module with shell=False instead of os.system, which is
deprecated and vulnerable to shell meta-character injection.

https://sources.debian.net/src/libgap-sage/4.8.3%2Bg69a66f0%2Bdsx-1/scripts/libGAPify.py/#L465

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Build-Depends on source itself [libgap-sage]

[Paul Wise]

On Wed, Nov 2, 2016 at 11:22 AM, Jerome BENOIT wrote:

> Let give a try. I am dealing with the libgap-sage package [1].

Thanks for the extensive details.

> To begin with, GAP is a Computer Algebra System (CAS).
> From an upstream point of view, libgap is not part of GAP itself.
> libgap is rather a library wrapper for gap meant to get a better
> access to the GAP kernel and to be used within Sage, which is a kind
> a umbrella for multiple CAS (GAP, Singular, and a myriad of scientific 
> oriented software packages).
> Note that, for now at least, GAP itself does not furnish any library; hence 
> libgap.

The libgap project seems like a workaround for this bug in GAP?

> Basically libgap adds a prefix to the GAP functions and variables,
> and gather them in a library. We must have in mind the following points:
> 1] The libgap source ball provides the modified source files with some delay
> (current modified gap version in libgap is 4.8.3 while the current gap 
> version is 4.8.5 ,
> this version being the one in Stretch. In any case, the copyright headers of 
> the source files
> are not modified, so they cannot be packaged for copyright reasons.

That seems like a very suboptimal way to do it.

> 2] The scripts that modify the original GAP source files is not distributed 
> within
> the libgap upstream source ball, but it is available via the libgap git 
> repository [2] at Bitbucket
> along some documentation for generating our own modified GAP source code. The 
> current Debian source ball
> for libgap is the git repository material (which unmodified contains but 
> obsolete GAP material, version 4.8.3).

Ok, I'm glad this is not a DFSG violation. It could easily have been one.

> 3] The libgap Debian package must be synchronized with the GAP Debian 
> package, so modifying the (potentially)
> patched GAP src/ is certainly not only a good idea but also a factor of 
> stability and good maintenance.

Agreed.

> 4] Just the material in the subfolder src/ within the GAP source ball is 
> needed, that is to say, not the all
> source ball.

Makes sense.

> 5] We want a long term solution to ease the maintenance of Sage[Math] and its 
> friends.

It seems clear to me that the only sane long-term solution is for GAP
upstream to add a proper shared library. Has this been discussed with
them at all? Until GAP upstream are willing to do this, I suggest one
of the following:

Drop the libgap-sage source package entirely and add a secondary
tarball to the Debian GAP source package containing only the libgap
scripts and have the Debian build process for GAP use those scripts to
create libgap-sage dev and lib binary packages. dpkg-source format v3
can have multiple tarballs, which makes this doable sanely.

OR

Get the GAP sources removed from the Bitbucket repository.

Have the build scripts in the libgap Bitbucket repository:

1. require info on which source tree to copy or which version to download
2. copy that source tree or download that version
3. modify the local copy using the scripts as per normal
4. build the scripts as per normal

There might need to be some checking of the copied source tree to make
sure the scripts still support it.

Create a gap-libgap-sage-source (or similar) package from the GAP
Debian package, containing the GAP src/ directory somewhere under
/usr/src.

Have the libgap-sage package build-depend on gap-libgap-sage-source
and point the libgap scripts at the GAP src/ directory under /usr/src.

Make sure that the libgap-sage package is binNMUed or rebuilt after
every gap upload. I expect the script will need to change reasonably
often due to changes in GAP though.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Build-Depends on source itself [libgap-sage]

[Jerome BENOIT]

Hello,


On 01/11/16 05:19, Paul Wise wrote:
> On Tue, Nov 1, 2016 at 12:43 PM, Jerome BENOIT wrote:
>
>> for one of my package, libgap-sage [1], the source material used for build
>> is in fact seded meterial from an other package, gap: grossely the sed 
>> process
>> is the main part of libgap package: is there a standard way to use the Debian
>> source package of gap inside my own package libgap-sage ?
>> Any hint or example is welcome.
>
> At this time there is no way for source packages to build-depend on
> other source packages.
>
> The most often used workaround for this is binary packages with
> -source at the end of their names:
>
> $ aptitude search -- -source$


On 01/11/16 17:47, Paul Wise wrote:
> On Wed, Nov 2, 2016 at 12:38 AM, Jerome BENOIT wrote:
> 
>> Is there any guidance for such source packages ? Which ones of them I may 
>> consider
>> a good example.
> 
> They are all about the same, ship the source under /usr/src, done.
> 
>> I guess it is the best way to proceed.
> 
> It is probably the least good way to proceed, please provide some
> details so we can discuss a proper solution.
> 

Let give a try. I am dealing with the libgap-sage package [1].

To begin with, GAP is a Computer Algebra System (CAS).
>From an upstream point of view, libgap is not part of GAP itself.
libgap is rather a library wrapper for gap meant to get a better
access to the GAP kernel and to be used within Sage, which is a kind
a umbrella for multiple CAS (GAP, Singular, and a myriad of scientific oriented 
software packages).
Note that, for now at least, GAP itself does not furnish any library; hence 
libgap.

Basically libgap adds a prefix to the GAP functions and variables,
and gather them in a library. We must have in mind the following points:
1] The libgap source ball provides the modified source files with some delay
(current modified gap version in libgap is 4.8.3 while the current gap version 
is 4.8.5 ,
this version being the one in Stretch. In any case, the copyright headers of 
the source files
are not modified, so they cannot be packaged for copyright reasons.
2] The scripts that modify the original GAP source files is not distributed 
within
the libgap upstream source ball, but it is available via the libgap git 
repository [2] at Bitbucket
along some documentation for generating our own modified GAP source code. The 
current Debian source ball
for libgap is the git repository material (which unmodified contains but 
obsolete GAP material, version 4.8.3).
3] The libgap Debian package must be synchronized with the GAP Debian package, 
so modifying the (potentially)
patched GAP src/ is certainly not only a good idea but also a factor of 
stability and good maintenance.
4] Just the material in the subfolder src/ within the GAP source ball is 
needed, that is to say, not the all
source ball.
5] We want a long term solution to ease the maintenance of Sage[Math] and its 
friends.

For now, instead of a full source package and as suggested by Ben Finney, I 
think that a pure technical package
that would contain main the src/ subfolder material is the best option.
Of course, I am willing to write the patch against the GAP debian/ material 
that will introduce this src package.
And, before all, it must be done with the agreement of the GAP Debian package 
maintainer.

Thanks,
Jerome


[1] https://packages.qa.debian.org/libg/libgap-sage.html
[2] https://bitbucket.org/vbraun/libgap

Re: Build-Depends on source itself

[Ben Finney]

Jerome BENOIT  writes:

> for one of my package, libgap-sage [1], the source material used for build
> is in fact seded meterial from an other package, gap

One good solution would be to have the ‘gap’ package build a new binary
package, maybe ‘gap-data’, that contains the data you need in a format
likely to be useful for many purposes.

Could you work with the ‘gap’ package maintainer to achieve that?

Once ‘gap-data’ (if that is the name the ‘gap’ maintainers decide)
exists, your poposed pacakge can “Build-Depends: gap-data” and work
forward from there.

-- 
 \   “Don't worry about what anybody else is going to do. The best |
  `\ way to predict the future is to invent it.” —Alan Kay |
_o__)  |
Ben Finney

Re: Build-Depends on source itself

[Paul Wise]

On Wed, Nov 2, 2016 at 12:38 AM, Jerome BENOIT wrote:

> Is there any guidance for such source packages ? Which ones of them I may 
> consider
> a good example.

They are all about the same, ship the source under /usr/src, done.

> I guess it is the best way to proceed.

It is probably the least good way to proceed, please provide some
details so we can discuss a proper solution.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Build-Depends on source itself

[Jerome BENOIT]

Hello, thanks for the quick reply.

On 01/11/16 05:19, Paul Wise wrote:
> On Tue, Nov 1, 2016 at 12:43 PM, Jerome BENOIT wrote:
> 
>> for one of my package, libgap-sage [1], the source material used for build
>> is in fact seded meterial from an other package, gap: grossely the sed 
>> process
>> is the main part of libgap package: is there a standard way to use the Debian
>> source package of gap inside my own package libgap-sage ?
>> Any hint or example is welcome.
> 
> At this time there is no way for source packages to build-depend on
> other source packages.
> 
> The most often used workaround for this is binary packages with
> -source at the end of their names:
> 
> $ aptitude search -- -source$

Is there any guidance for such source packages ? Which ones of them I may 
consider
a good example.


> 
> If you can provide some details about your situation, we can probably
> find a better solution.
> 

I guess it is the best way to proceed.

Thanks,
Jerome

Re: Build-Depends on source itself

[Paul Wise]

On Tue, Nov 1, 2016 at 12:43 PM, Jerome BENOIT wrote:

> for one of my package, libgap-sage [1], the source material used for build
> is in fact seded meterial from an other package, gap: grossely the sed process
> is the main part of libgap package: is there a standard way to use the Debian
> source package of gap inside my own package libgap-sage ?
> Any hint or example is welcome.

At this time there is no way for source packages to build-depend on
other source packages.

The most often used workaround for this is binary packages with
-source at the end of their names:

$ aptitude search -- -source$

If you can provide some details about your situation, we can probably
find a better solution.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Build-Depends versioning and binary Depends versioning

[Andrey Rahmatullin]

On Wed, Mar 20, 2013 at 07:17:50PM +0100, Paul Gevers wrote:
  Maybe I've picked the wrong example, the actual problem was with
  libavdevice53, the same soname is used for either 0.8.5-1 and 9.3-1,
  but 9.3-1 links to libavcodec54 while 0.8.5-1 links to libavcodec53, so
  my binary ended up importing either libavcodec53 and libavcodec54 when
  both were installed and did not work.
 If this is true, and I must say I may have had the same experience,
 isn't this hinting at a bug in libavdevice53, not being stable enough to
 keep the same SONAME? I think you should file a bug against libavdevice53.
Why? The problem is caused by indirect dependency on both libavcodec53 and
libavcodec54, not by ABI breakage.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Build-Depends versioning and binary Depends versioning

[Paul Gevers]

Hi Andrey,

On 21-03-13 07:46, Andrey Rahmatullin wrote:
 On Wed, Mar 20, 2013 at 07:17:50PM +0100, Paul Gevers wrote:
 Maybe I've picked the wrong example, the actual problem was with
 libavdevice53, the same soname is used for either 0.8.5-1 and 9.3-1,
 but 9.3-1 links to libavcodec54 while 0.8.5-1 links to libavcodec53, so
 my binary ended up importing either libavcodec53 and libavcodec54 when
 both were installed and did not work.
 If this is true, and I must say I may have had the same experience,
 isn't this hinting at a bug in libavdevice53, not being stable enough to
 keep the same SONAME? I think you should file a bug against libavdevice53.
 Why? The problem is caused by indirect dependency on both libavcodec53 and
 libavcodec54, not by ABI breakage.

Could you please explain what the problem is then becasue I don't see it
(I really want to learn here). As I understand it, if you get
libavdevice53 in a newer version it should still work with stuff that
was build against an older version, right? If it breaks, the soname
should be updated and the packagename changed, so that the libraries can
be co-installed. So I guess you see the problem elsewhere?

Paul





signature.asc
Description: OpenPGP digital signature

Re: Build-Depends versioning and binary Depends versioning

[Andrey Rahmatullin]

On Thu, Mar 21, 2013 at 08:04:10AM +0100, Paul Gevers wrote:
  Maybe I've picked the wrong example, the actual problem was with
  libavdevice53, the same soname is used for either 0.8.5-1 and 9.3-1,
  but 9.3-1 links to libavcodec54 while 0.8.5-1 links to libavcodec53, so
  my binary ended up importing either libavcodec53 and libavcodec54 when
  both were installed and did not work.
  If this is true, and I must say I may have had the same experience,
  isn't this hinting at a bug in libavdevice53, not being stable enough to
  keep the same SONAME? I think you should file a bug against libavdevice53.
  Why? The problem is caused by indirect dependency on both libavcodec53 and
  libavcodec54, not by ABI breakage.
 Could you please explain what the problem is then becasue I don't see it
 (I really want to learn here). As I understand it, if you get
 libavdevice53 in a newer version it should still work with stuff that
 was build against an older version, right? If it breaks, the soname
 should be updated and the packagename changed, so that the libraries can
 be co-installed. So I guess you see the problem elsewhere?
If your app is linked against libavcodec53 and against libavdevice53 and
libavdevice53 is linked against libavcodec54 and libavcodec* doesn't use
symbol versioning, your app will crash because of symbol conflicts.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Build-Depends versioning and binary Depends versioning

[Paul Gevers]

Please ignore the mail below, I think I understand that part now.

libavdevice53 itself depends on libavcodec5{3|4} depending on where it
comes from.

Paul

On 21-03-13 08:04, Paul Gevers wrote:
 Hi Andrey,
 
 On 21-03-13 07:46, Andrey Rahmatullin wrote:
 On Wed, Mar 20, 2013 at 07:17:50PM +0100, Paul Gevers wrote:
 Maybe I've picked the wrong example, the actual problem was with
 libavdevice53, the same soname is used for either 0.8.5-1 and 9.3-1,
 but 9.3-1 links to libavcodec54 while 0.8.5-1 links to libavcodec53, so
 my binary ended up importing either libavcodec53 and libavcodec54 when
 both were installed and did not work.
 If this is true, and I must say I may have had the same experience,
 isn't this hinting at a bug in libavdevice53, not being stable enough to
 keep the same SONAME? I think you should file a bug against libavdevice53.
 Why? The problem is caused by indirect dependency on both libavcodec53 and
 libavcodec54, not by ABI breakage.
 
 Could you please explain what the problem is then becasue I don't see it
 (I really want to learn here). As I understand it, if you get
 libavdevice53 in a newer version it should still work with stuff that
 was build against an older version, right? If it breaks, the soname
 should be updated and the packagename changed, so that the libraries can
 be co-installed. So I guess you see the problem elsewhere?
 
 Paul
 
 
 




signature.asc
Description: OpenPGP digital signature

Re: Build-Depends versioning and binary Depends versioning

[Russ Allbery]

Andrey Rahmatullin w...@wrar.name writes:

 If your app is linked against libavcodec53 and against libavdevice53 and
 libavdevice53 is linked against libavcodec54 and libavcodec* doesn't use
 symbol versioning, your app will crash because of symbol conflicts.

Which is why all shared libraries should use at least trivial symbol
versioning that assigns all symbols a version that changes with the
SONAME.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87li9gsp60@windlord.stanford.edu

Re: Build-Depends versioning and binary Depends versioning

[Paul Wise]

On Fri, Mar 22, 2013 at 12:17 AM, Russ Allbery wrote:

 Which is why all shared libraries should use at least trivial symbol
 versioning that assigns all symbols a version that changes with the
 SONAME.

Perhaps a pedantic/info lintian complaint is in order?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKTje6FoB=jo3byas5vuqx4okktisr17ourqkgac-9reif1...@mail.gmail.com

Re: Build-Depends versioning and binary Depends versioning

[Antonio Ospite]

On Tue, 19 Mar 2013 18:51:26 +0100
Jakub Wilk jw...@debian.org wrote:

 * Antonio Ospite osp...@studenti.unina.it, 2013-03-19, 16:15:
 for a package I am working on, I am setting versioned Build-Depends, to 
 avoid using newer libav versions which would break compilation, e.g.:
 
  libavcodec-dev ( 6:9)
 
 Compilation under pbuilder for Sid goes fine, but the binary packages 
 are still allowed to be installed with newer libav binary packages:
 
   libavcodec53 (= 6:0.8.3-1~) | libavcodec-extra-53 (= 6:0.8.5)
 
 A well-behaved shared library package won't break binary compatibility 
 without changing package name. In fact, the package name has changed to 
 libavcodec54. So nothing wrong with the dependency as far as I can tell.
 

Maybe I've picked the wrong example, the actual problem was with
libavdevice53, the same soname is used for either 0.8.5-1 and 9.3-1,
but 9.3-1 links to libavcodec54 while 0.8.5-1 links to libavcodec53, so
my binary ended up importing either libavcodec53 and libavcodec54 when
both were installed and did not work.

I think it will be enough to require libavdevice53 ( 6:9) in my case.

Thanks,
   Antonio

-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130320155413.b8798d09e5005c0425f81...@studenti.unina.it

Re: Build-Depends versioning and binary Depends versioning

[Antonio Ospite]

On Tue, 19 Mar 2013 10:10:51 -0700
Russ Allbery r...@debian.org wrote:

 Antonio Ospite osp...@studenti.unina.it writes:
 
  Should I restrict the Depends for the binary packages by hand in
  debian/control? For example adding:
 
  libavcodec53 ( 6:9)
 
  to the binary package I am interested in restricting?
 
 Yes.  The shared library dependency information otherwise comes from
 shlibs/symbols, which won't take into account restrictions on the build
 dependency.
 

Thanks Russ.

-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130320155440.7f0611c46f2046d604dea...@studenti.unina.it

Re: Build-Depends versioning and binary Depends versioning

[Andrey Rahmatullin]

On Wed, Mar 20, 2013 at 03:54:13PM +0100, Antonio Ospite wrote:
 Maybe I've picked the wrong example, the actual problem was with
 libavdevice53, the same soname is used for either 0.8.5-1 and 9.3-1,
 but 9.3-1 links to libavcodec54 while 0.8.5-1 links to libavcodec53, so
 my binary ended up importing either libavcodec53 and libavcodec54 when
 both were installed and did not work.
 
 I think it will be enough to require libavdevice53 ( 6:9) in my case.
Strictly speaking this restriction won't guarantee anything about
libavdevice53 dependencies.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Build-Depends versioning and binary Depends versioning

[Paul Gevers]

On 20-03-13 15:54, Antonio Ospite wrote:
 Maybe I've picked the wrong example, the actual problem was with
 libavdevice53, the same soname is used for either 0.8.5-1 and 9.3-1,
 but 9.3-1 links to libavcodec54 while 0.8.5-1 links to libavcodec53, so
 my binary ended up importing either libavcodec53 and libavcodec54 when
 both were installed and did not work.

If this is true, and I must say I may have had the same experience,
isn't this hinting at a bug in libavdevice53, not being stable enough to
keep the same SONAME? I think you should file a bug against libavdevice53.

Paul



signature.asc
Description: OpenPGP digital signature

Re: Build-Depends versioning and binary Depends versioning

[Andrey Rahmatullin]

On Tue, Mar 19, 2013 at 04:15:57PM +0100, Antonio Ospite wrote:
 Compilation under pbuilder for Sid goes fine, but the binary packages
 are still allowed to be installed with newer libav binary packages:
 
libavcodec53 (= 6:0.8.3-1~) | libavcodec-extra-53 (= 6:0.8.5)
Of course, because it is expected that a binary built with a given library
version will work with all newer versions of that library having the same
soname.

 As you can see I can still install the package on a system which has
 libavcodec53 9.3-1 from experimental, as the binary dependency is
 just greater than, the strictly minor one from the Build-Depends didn't
 propagate to the binary packages.
Of course it didn't, there is no such mechanisms because there is no need
for them.

 Thinking about it I can see why this is happening: I specified the
 Build-Depends for the -dev packages, not for the corresponding
 libraries, but naively I thought the build system can figure out the
 relationship between the two.
It cannot and it would be strange if it did.

 Should I restrict the Depends for the binary packages by hand in
 debian/control?
Do you have any reasons to do that? Are you sure that the package will not
work with newer versions?

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Build-Depends versioning and binary Depends versioning

[Russ Allbery]

Antonio Ospite osp...@studenti.unina.it writes:

 Should I restrict the Depends for the binary packages by hand in
 debian/control? For example adding:

   libavcodec53 ( 6:9)

 to the binary package I am interested in restricting?

Yes.  The shared library dependency information otherwise comes from
shlibs/symbols, which won't take into account restrictions on the build
dependency.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87a9pziack@windlord.stanford.edu

Re: Build-Depends versioning and binary Depends versioning

[Jakub Wilk]

* Antonio Ospite osp...@studenti.unina.it, 2013-03-19, 16:15:
for a package I am working on, I am setting versioned Build-Depends, to 
avoid using newer libav versions which would break compilation, e.g.:


libavcodec-dev ( 6:9)

Compilation under pbuilder for Sid goes fine, but the binary packages 
are still allowed to be installed with newer libav binary packages:


 libavcodec53 (= 6:0.8.3-1~) | libavcodec-extra-53 (= 6:0.8.5)


A well-behaved shared library package won't break binary compatibility 
without changing package name. In fact, the package name has changed to 
libavcodec54. So nothing wrong with the dependency as far as I can tell.


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130319175126.ga5...@jwilk.net

Re: Build-Depends-Indep, please review

[Goswin von Brederlow]

Roger Leigh rle...@codelibre.net writes:

 On Sun, Nov 21, 2010 at 07:09:44PM +0100, Goswin von Brederlow wrote:
  Output at http://people.debian.org/~rleigh/build-rule-check.bz2
  I haven't had time to analyse this, if someone else wants to,
  that would be cool.
 
  Done on lintian.debian.org using the following:
 
  #!/bin/sh
 
  cd /srv/lintian.debian.org/laboratory/source
  find . -type f -name rules | grep 'debfiles/rules$' | while read rule
  do
egrep -H '^(build(.*%)?|build-(arch|indep)):' $rule
  done
 
 
  Regards,
  Roger
 
 Now why does it only list 8k sources if it matches the required
 build: target? Are 50% of all sources already dropping through that
 grep because they use dh ('%:') or include files?

 That's what I think, and a cursory look at a few gives the same
 impression.  Which is surprisingly good--there's only a single
 tool to update to get support added for a huge chunk of the
 archive (well, there's cdbs as well of course, so it's two main
 ones).

I would think dh already supports them. So we might actuay have 50%
coverage of binay-arch/indep already or verry close to it.

Maybe we can actualy change policy post squeeze because the majority of
sources supports it.

 Anyway, grepping for sources that (probably) have build-arch/indep:
 
 % bzcat build-rule-check.bz2 | egrep 
 '/rules:(build(.*%)+|build-(arch|indep)):' | cut -d: -f1 | sort -u | wc -l
 572
 
 Lots of work to do.

 Agreed!  But, should be an achievable goal for squeeze+1 if we start
 on it early.

 Regards,
 Roger

Totaly.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r5edibvo@frosties.localnet

Re: Build-Depends-Indep, please review

[Roger Leigh]

On Mon, Nov 22, 2010 at 05:03:39PM +0100, Goswin von Brederlow wrote:
 Roger Leigh rle...@codelibre.net writes:
 
  On Sun, Nov 21, 2010 at 07:09:44PM +0100, Goswin von Brederlow wrote:
  
  Now why does it only list 8k sources if it matches the required
  build: target? Are 50% of all sources already dropping through that
  grep because they use dh ('%:') or include files?
 
  That's what I think, and a cursory look at a few gives the same
  impression.  Which is surprisingly good--there's only a single
  tool to update to get support added for a huge chunk of the
  archive (well, there's cdbs as well of course, so it's two main
  ones).
 
 I would think dh already supports them. So we might actuay have 50%
 coverage of binay-arch/indep already or verry close to it.
 
 Maybe we can actualy change policy post squeeze because the majority of
 sources supports it.

I checked, and dh currently doesn't support build-arch and build-indep
at all internally (you need to add the rules yourself).  I've made a
patch to add proper support which I'll submit once I've tested it.

I've submitted a proposed change to Policy to require the use
of these targets (#604397), but we need at least 50% coverage first.
But, we'll get that as soon as dh and cdbs support it.

We also need a lintian check to warn if these targets are missing;
but I'm not at all familiar with hacking on lintian.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: Build-Depends-Indep, please review

[Roger Leigh]

On Mon, Nov 22, 2010 at 04:39:20PM +, Roger Leigh wrote:
 I checked, and dh currently doesn't support build-arch and build-indep
 at all internally (you need to add the rules yourself).  I've made a
 patch to add proper support which I'll submit once I've tested it.

FWIW, the current progress on this is attached.  No guarantees--it's
totally untested.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.
diff --git a/dh b/dh
index d2771ab..794ff4f 100755
--- a/dh
+++ b/dh
@@ -16,13 +16,15 @@ Bdh Isequence [B--with Iaddon[B,Iaddon ...]] [B--list] [B--until
 =head1 DESCRIPTION
 
 Bdh runs a sequence of debhelper commands. The supported Isequences
-correspond to the targets of a Fdebian/rules file: Bbuild, Bclean,
-Binstall, Bbinary-arch, Bbinary-indep, and Bbinary.
+correspond to the targets of a Fdebian/rules file: Bbuild-arch,
+Bbuild-indep, Bbuild, Bclean, Binstall, Bbinary-arch,
+Bbinary-indep, and Bbinary.
 
-Commands in the Bbinary-indep sequence are passed the B-i option to ensure
-they only work on binary independent packages, and commands in the
-Bbinary-arch sequences are passed the B-a option to ensure they only work
-on architecture dependent packages.
+Commands in the Bbuild-indep and Bbinary-indep sequences are passed
+the B-i option to ensure they only work on binary independent packages,
+and commands in the Bbuild-arch and Bbinary-arch sequences are
+passed the B-a option to ensure they only work on architecture
+dependent packages.
 
 If Fdebian/rules contains a target with a name like Boverride_Idh_command,
 then when it would normally run Idh_command, Bdh will instead call that
@@ -322,6 +324,8 @@ $sequences{build} = [qw{
 	dh_auto_build
 	dh_auto_test
 }],
+$sequences{'build-indep'} = [...@{$sequences{build}}];
+$sequences{'build-arch'} = [...@{$sequences{build}}];
 $sequences{clean} = [qw{
 	dh_testdir
 	dh_auto_clean
@@ -367,19 +371,25 @@ $sequences{install} = [...@{$sequences{build}}, qw{
 	dh_compress
 	dh_fixperms
 }];
+$sequences{install-indep} = [...@{$sequences{build-indep}}, @i];
+$sequences{install-arch} = [...@{$sequences{build-arch}}, @i];
 my @b=qw{
 	dh_installdeb
 	dh_gencontrol
 	dh_md5sums
 	dh_builddeb
 };
-$sequences{'binary-indep'} = [...@{$sequences{install}}, @b];
+$sequences{'binary-indep'} = [...@{$sequences{install-indep}}, @b];
 $sequences{binary} = [...@{$sequences{install}}, qw{
 	dh_strip
 	dh_makeshlibs
 	dh_shlibdeps
 }, @b];
-$sequences{'binary-arch'} = [...@{$sequences{binary}}];
+$sequences{'binary-arch'} = [...@{$sequences{install-arch}}, qw{
+	dh_strip
+	dh_makeshlibs
+	dh_shlibdeps
+}];
 
 # Additional command options
 my %command_opts;
@@ -514,14 +524,18 @@ my @packag...@{$dh{dopackages}};
 # Get the options to pass to commands in the sequence.
 # Filter out options intended only for this program.
 my @options;
-if ($sequence eq 'binary-arch') {
+if ($sequence eq 'build-arch' ||
+$sequence eq 'install-arch' ||
+$sequence eq 'binary-arch') {
 	push @options, -a;
 	# as an optimisation, remove from the list any packages
 	# that are not arch dependent
 	my %arch_packages = map { $_ = 1 } getpackages(arch);
 	@packages = grep { $arch_packages{$_} } @packages;
 }
-elsif ($sequence eq 'binary-indep') {
+elsif ($sequence eq 'build-indep' ||
+   $sequence eq 'install-indep' ||
+   $sequence eq 'binary-indep') {
 	push @options, -i;
 	# ditto optimisation for arch indep
 	my %indep_packages = map { $_ = 1 } getpackages(indep);


signature.asc
Description: Digital signature

Re: Build-Depends-Indep, please review

[Roger Leigh]

On Mon, Nov 22, 2010 at 04:42:03PM +, Roger Leigh wrote:
 On Mon, Nov 22, 2010 at 04:39:20PM +, Roger Leigh wrote:
  I checked, and dh currently doesn't support build-arch and build-indep
  at all internally (you need to add the rules yourself).  I've made a
  patch to add proper support which I'll submit once I've tested it.
 
 FWIW, the current progress on this is attached.  No guarantees--it's
 totally untested.

Final tested patch in #604563.


-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: Build-Depends-Indep, please review

[Goswin von Brederlow]

Roger Leigh rle...@codelibre.net writes:

 On Sat, Nov 20, 2010 at 08:23:59PM +, Roger Leigh wrote:
 On Sat, Nov 20, 2010 at 01:29:12PM -0600, Boyd Stephen Smith Jr. wrote:
  In 20101120183255.gf12...@khazad-dum.debian.net, Henrique de Moraes 
  Holschuh 
  wrote:
  On Fri, 19 Nov 2010, Boyd Stephen Smith Jr. wrote:
   But hey, all the maintainer has to do is add 1, in words ONE, char to
   debian/rules. Just change build: to build%: and dpkg-buildpackage
   could use build-arch/indep targets instead of build. Aparently that is
   too much to ask.
   
   I volunteer to make /this/ fix to any package that is unmaintained or
   whose maintainer is unresponsive, *if* Debian will change policy to
   /require/ build- arch/indep and make dpkg-buildpackage use them instead
   of build sometime after the Squeeze release and before the Wheezy 
   freeze.
  
  It can be done, but it must be done in at least two steps:
  
  1. Make it SHOULD, start fixing packages.  You don't have to wait for the
 SHOULD to start fixing packages, either.
  
  I'm not willing to manually test random packages for this breakage.  
  What's 
  the best way to get an automated process to report on the PTS or BTS the 
  existence of build-arch and build-indep?  Could it simply be a lintian 
  test?
  
  Also, I thought it was already a SHOULD.
  
  2. When almost everything is fixed, make it MUST.  Whatever doesn't get
 fixed after that, gets axed from the next stable.
  
  My time was volunteered (in my last posting) *after* it becomes a MUST, 
  but 
  with some help I might be willing to put some time in as part of a DEP.
 
 Two suggestions:
 
r 1) Use the lintian lab on lintian.debian.org
(/v/lintian.debian.org/laboratory) which contains all 15796 unpacked
source packages.  Alternatively, download and unpack them all on your
own machine []
 
You can write a script to check for the presence of build-arch:
and/or build-indep:
Note: this won't pick out make pattern rules which don't have
(directly) those named rules, so you might want to check for build%
etc.  There are other special cases such as included Makefiles when
packages use cdbs etc., so you will get false positives that need
manual review.
 
Example: find . -type f -name rules | grep 'debian/rules$' | while read 
 rule; do egrep -H '^(build(.*%)?|build-(arch|indep)):' $rule; done
gives you somewhere to start.

 Output at http://people.debian.org/~rleigh/build-rule-check.bz2
 I haven't had time to analyse this, if someone else wants to,
 that would be cool.

 Done on lintian.debian.org using the following:

 #!/bin/sh

 cd /srv/lintian.debian.org/laboratory/source
 find . -type f -name rules | grep 'debfiles/rules$' | while read rule
 do
   egrep -H '^(build(.*%)?|build-(arch|indep)):' $rule
 done


 Regards,
 Roger

Now why does it only list 8k sources if it matches the required
build: target? Are 50% of all sources already dropping through that
grep because they use dh ('%:') or include files?

Anyway, grepping for sources that (probably) have build-arch/indep:

% bzcat build-rule-check.bz2 | egrep '/rules:(build(.*%)+|build-(arch|indep)):' 
| cut -d: -f1 | sort -u | wc -l
572

Lots of work to do.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ipzqblav@frosties.localnet

Re: Build-Depends-Indep, please review

[Roger Leigh]

On Sun, Nov 21, 2010 at 07:09:44PM +0100, Goswin von Brederlow wrote:
  Output at http://people.debian.org/~rleigh/build-rule-check.bz2
  I haven't had time to analyse this, if someone else wants to,
  that would be cool.
 
  Done on lintian.debian.org using the following:
 
  #!/bin/sh
 
  cd /srv/lintian.debian.org/laboratory/source
  find . -type f -name rules | grep 'debfiles/rules$' | while read rule
  do
egrep -H '^(build(.*%)?|build-(arch|indep)):' $rule
  done
 
 
  Regards,
  Roger
 
 Now why does it only list 8k sources if it matches the required
 build: target? Are 50% of all sources already dropping through that
 grep because they use dh ('%:') or include files?

That's what I think, and a cursory look at a few gives the same
impression.  Which is surprisingly good--there's only a single
tool to update to get support added for a huge chunk of the
archive (well, there's cdbs as well of course, so it's two main
ones).

 Anyway, grepping for sources that (probably) have build-arch/indep:
 
 % bzcat build-rule-check.bz2 | egrep 
 '/rules:(build(.*%)+|build-(arch|indep)):' | cut -d: -f1 | sort -u | wc -l
 572
 
 Lots of work to do.

Agreed!  But, should be an achievable goal for squeeze+1 if we start
on it early.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: Build-Depends-Indep, please review

[Henrique de Moraes Holschuh]

On Fri, 19 Nov 2010, Boyd Stephen Smith Jr. wrote:
 But hey, all the maintainer has to do is add 1, in words ONE, char to
 debian/rules. Just change build: to build%: and dpkg-buildpackage
 could use build-arch/indep targets instead of build. Aparently that is
 too much to ask.
 
 I volunteer to make /this/ fix to any package that is unmaintained or whose 
 maintainer is unresponsive, *if* Debian will change policy to /require/ build-
 arch/indep and make dpkg-buildpackage use them instead of build sometime 
 after 
 the Squeeze release and before the Wheezy freeze.

It can be done, but it must be done in at least two steps:

1. Make it SHOULD, start fixing packages.  You don't have to wait for the
   SHOULD to start fixing packages, either.

2. When almost everything is fixed, make it MUST.  Whatever doesn't get
   fixed after that, gets axed from the next stable.

-- 
  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


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101120183255.gf12...@khazad-dum.debian.net

Re: Build-Depends-Indep, please review

[Boyd Stephen Smith Jr.]

In 20101120183255.gf12...@khazad-dum.debian.net, Henrique de Moraes Holschuh 
wrote:
On Fri, 19 Nov 2010, Boyd Stephen Smith Jr. wrote:
 But hey, all the maintainer has to do is add 1, in words ONE, char to
 debian/rules. Just change build: to build%: and dpkg-buildpackage
 could use build-arch/indep targets instead of build. Aparently that is
 too much to ask.
 
 I volunteer to make /this/ fix to any package that is unmaintained or
 whose maintainer is unresponsive, *if* Debian will change policy to
 /require/ build- arch/indep and make dpkg-buildpackage use them instead
 of build sometime after the Squeeze release and before the Wheezy freeze.

It can be done, but it must be done in at least two steps:

1. Make it SHOULD, start fixing packages.  You don't have to wait for the
   SHOULD to start fixing packages, either.

I'm not willing to manually test random packages for this breakage.  What's 
the best way to get an automated process to report on the PTS or BTS the 
existence of build-arch and build-indep?  Could it simply be a lintian test?

Also, I thought it was already a SHOULD.

2. When almost everything is fixed, make it MUST.  Whatever doesn't get
   fixed after that, gets axed from the next stable.

My time was volunteered (in my last posting) *after* it becomes a MUST, but 
with some help I might be willing to put some time in as part of a DEP.
-- 
Boyd Stephen Smith Jr.   ,= ,-_-. =.
b...@iguanasuicide.net   ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/


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

Re: Build-Depends-Indep, please review

[Goswin von Brederlow]

Boyd Stephen Smith Jr. b...@iguanasuicide.net writes:

 In 20101120183255.gf12...@khazad-dum.debian.net, Henrique de Moraes 
 Holschuh 
 wrote:
On Fri, 19 Nov 2010, Boyd Stephen Smith Jr. wrote:
 But hey, all the maintainer has to do is add 1, in words ONE, char to
 debian/rules. Just change build: to build%: and dpkg-buildpackage
 could use build-arch/indep targets instead of build. Aparently that is
 too much to ask.
 
 I volunteer to make /this/ fix to any package that is unmaintained or
 whose maintainer is unresponsive, *if* Debian will change policy to
 /require/ build- arch/indep and make dpkg-buildpackage use them instead
 of build sometime after the Squeeze release and before the Wheezy freeze.

It can be done, but it must be done in at least two steps:

1. Make it SHOULD, start fixing packages.  You don't have to wait for the
   SHOULD to start fixing packages, either.

 I'm not willing to manually test random packages for this breakage.  What's 
 the best way to get an automated process to report on the PTS or BTS the 
 existence of build-arch and build-indep?  Could it simply be a lintian test?

Setup an autobuilder, patch dpkg-buildpackage to call build-arch/indep,
rebuild all packages, read all failed build logs.


You could set up a lintian test that checks for a targets compatible
with build-arch/indep to get a fairly goo result. I.e. '%' is compatible,
'build%' is and so on. You will get some false positives and false
negatives but for a lintian test that should be ok. Unfortunately it
isn't good enough for dpkg-buildpackage use.

If you have the knowledge to write lintian tests then please do.

 Also, I thought it was already a SHOULD.

It is more a CAN. The targets are declared optional without a statement
one SHOULD have them even if they only depend on 'build'.

2. When almost everything is fixed, make it MUST.  Whatever doesn't get
   fixed after that, gets axed from the next stable.

 My time was volunteered (in my last posting) *after* it becomes a MUST, but 
 with some help I might be willing to put some time in as part of a DEP.

And that is the problem. You will only do the work if you MUST. And you
only MUST if the work is almost done.

The same goes for maintainers accepting patches. There are a lot of
sources, maybe even the majority, where build-arch/indep is of no
use. And there maintainers are adverse to adding a patch for
build-arch/indep that is totaly useless (for their source).


Why not loosen your requirement a bit? For example would you volunteer
to NMU packages if build-arch/indep targets become a release goal for
wheeze?

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87tyjb3g00@frosties.localnet

Re: Build-Depends-Indep, please review

[Roger Leigh]

On Sat, Nov 20, 2010 at 01:29:12PM -0600, Boyd Stephen Smith Jr. wrote:
 In 20101120183255.gf12...@khazad-dum.debian.net, Henrique de Moraes 
 Holschuh 
 wrote:
 On Fri, 19 Nov 2010, Boyd Stephen Smith Jr. wrote:
  But hey, all the maintainer has to do is add 1, in words ONE, char to
  debian/rules. Just change build: to build%: and dpkg-buildpackage
  could use build-arch/indep targets instead of build. Aparently that is
  too much to ask.
  
  I volunteer to make /this/ fix to any package that is unmaintained or
  whose maintainer is unresponsive, *if* Debian will change policy to
  /require/ build- arch/indep and make dpkg-buildpackage use them instead
  of build sometime after the Squeeze release and before the Wheezy freeze.
 
 It can be done, but it must be done in at least two steps:
 
 1. Make it SHOULD, start fixing packages.  You don't have to wait for the
SHOULD to start fixing packages, either.
 
 I'm not willing to manually test random packages for this breakage.  What's 
 the best way to get an automated process to report on the PTS or BTS the 
 existence of build-arch and build-indep?  Could it simply be a lintian test?
 
 Also, I thought it was already a SHOULD.
 
 2. When almost everything is fixed, make it MUST.  Whatever doesn't get
fixed after that, gets axed from the next stable.
 
 My time was volunteered (in my last posting) *after* it becomes a MUST, but 
 with some help I might be willing to put some time in as part of a DEP.

Two suggestions:

1) Use the lintian lab on lintian.debian.org
   (/srv/lintian.debian.org/laboratory) which contains all 15796 unpacked
   source packages.  Alternatively, download and unpack them all on your
   own machine []

   You can write a script to check for the presence of build-arch:
   and/or build-indep:
   Note: this won't pick out make pattern rules which don't have
   (directly) those named rules, so you might want to check for build%
   etc.  There are other special cases such as included Makefiles when
   packages use cdbs etc., so you will get false positives that need
   manual review.

   Example: find . -type f -name rules | grep 'debian/rules$' | while read 
rule; do egrep -H '^(build(.*%)?|build-(arch|indep)):' $rule; done
   gives you somewhere to start.

2) Directly patch dpkg-buildpackage and do a whole-archive rebuild.

   If you patch dpkg-buildpackage to require build-arch and build-indep
   in place of build, you can then build every source package and get
   success or failure.

   This can be done fairly trivially by scripting sbuild to build all
   sources with the new dpkg-buildpackage installed in the build chroot.
   There's also rebuildd for use with pbuilder/cowbuilder if you prefer
   that.

   This will take much longer, but should be 100% reliable bar FTBFS
   bugs.

If there was a reliable way of getting make to tell you if a target
rule exists or not, that would be much quicker than doing a full
rebuild.  Additionally, it could be added to lintian to warn people
about the requirement.

Totally agree with hmh about making it a SHOULD in Policy followed by
MUST.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: Build-Depends-Indep, please review

[Roger Leigh]

On Sat, Nov 20, 2010 at 08:23:59PM +, Roger Leigh wrote:
 On Sat, Nov 20, 2010 at 01:29:12PM -0600, Boyd Stephen Smith Jr. wrote:
  In 20101120183255.gf12...@khazad-dum.debian.net, Henrique de Moraes 
  Holschuh 
  wrote:
  On Fri, 19 Nov 2010, Boyd Stephen Smith Jr. wrote:
   But hey, all the maintainer has to do is add 1, in words ONE, char to
   debian/rules. Just change build: to build%: and dpkg-buildpackage
   could use build-arch/indep targets instead of build. Aparently that is
   too much to ask.
   
   I volunteer to make /this/ fix to any package that is unmaintained or
   whose maintainer is unresponsive, *if* Debian will change policy to
   /require/ build- arch/indep and make dpkg-buildpackage use them instead
   of build sometime after the Squeeze release and before the Wheezy freeze.
  
  It can be done, but it must be done in at least two steps:
  
  1. Make it SHOULD, start fixing packages.  You don't have to wait for the
 SHOULD to start fixing packages, either.
  
  I'm not willing to manually test random packages for this breakage.  What's 
  the best way to get an automated process to report on the PTS or BTS the 
  existence of build-arch and build-indep?  Could it simply be a lintian test?
  
  Also, I thought it was already a SHOULD.
  
  2. When almost everything is fixed, make it MUST.  Whatever doesn't get
 fixed after that, gets axed from the next stable.
  
  My time was volunteered (in my last posting) *after* it becomes a MUST, but 
  with some help I might be willing to put some time in as part of a DEP.
 
 Two suggestions:
 
r 1) Use the lintian lab on lintian.debian.org
(/v/lintian.debian.org/laboratory) which contains all 15796 unpacked
source packages.  Alternatively, download and unpack them all on your
own machine []
 
You can write a script to check for the presence of build-arch:
and/or build-indep:
Note: this won't pick out make pattern rules which don't have
(directly) those named rules, so you might want to check for build%
etc.  There are other special cases such as included Makefiles when
packages use cdbs etc., so you will get false positives that need
manual review.
 
Example: find . -type f -name rules | grep 'debian/rules$' | while read 
 rule; do egrep -H '^(build(.*%)?|build-(arch|indep)):' $rule; done
gives you somewhere to start.

Output at http://people.debian.org/~rleigh/build-rule-check.bz2
I haven't had time to analyse this, if someone else wants to,
that would be cool.

Done on lintian.debian.org using the following:

#!/bin/sh

cd /srv/lintian.debian.org/laboratory/source
find . -type f -name rules | grep 'debfiles/rules$' | while read rule
do
  egrep -H '^(build(.*%)?|build-(arch|indep)):' $rule
done


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: Build-Depends-Indep, please review

[Goswin von Brederlow]

David Kalnischkies kalnischk...@gmail.com writes:

 On Thu, Nov 18, 2010 at 19:25, أحمد المحمودي 
 aelmahmo...@sabily.org wrote:
 On Thu, Nov 18, 2010 at 07:07:07PM +0100, Goswin von Brederlow wrote:
 And as discussed before policy disagrees with reality in this.

 Would you please elaborate ?

 Goswin likely refers to this thread: Buildd  binary-indep
 http://lists.debian.org/debian-devel/2010/09/msg00590.html
 Message-id: 20100924204433.ga4...@apache.rbscorp.ru


 Best regards

 David Kalnischkies

And in short:

Buildds install only Build-Depends but not Build-Depends-Indep but still
call the build target. In reality the build target must work with
only Build-Depends installed contrary to what policy says.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87y68pl3sm@frosties.localnet

Re: Build-Depends-Indep, please review

[Roger Leigh]

On Fri, Nov 19, 2010 at 04:40:57PM +0100, Goswin von Brederlow wrote:
 David Kalnischkies kalnischk...@gmail.com writes:
 
  On Thu, Nov 18, 2010 at 19:25, أحمد المحمودي 
  aelmahmo...@sabily.org wrote:
  On Thu, Nov 18, 2010 at 07:07:07PM +0100, Goswin von Brederlow wrote:
  And as discussed before policy disagrees with reality in this.
 
  Would you please elaborate ?
 
  Goswin likely refers to this thread: Buildd  binary-indep
  http://lists.debian.org/debian-devel/2010/09/msg00590.html
  Message-id: 20100924204433.ga4...@apache.rbscorp.ru
 
 
  Best regards
 
  David Kalnischkies
 
 And in short:
 
 Buildds install only Build-Depends but not Build-Depends-Indep but still
 call the build target. In reality the build target must work with
 only Build-Depends installed contrary to what policy says.

I do hope this mess can be sorted out after squeeze is released.
Mandating build-arch and build-indep would be a good thing, IMHO.
It's not the buildd software that can change this though--the
actual sticking point is dpkg-buildpackage, which is used by sbuild.

sbuild is actually perfectly capable of installing Build-Depends-Indep
and removing Build-Conflicts-Indep when invoked with the -A (build
arch-all) option, but there are no buildds building arch-indep packages
yet.  If we ever throw away uploaded binaries and build everything on
buildds, this would then be useful.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: Build-Depends-Indep, please review

[Goswin von Brederlow]

Roger Leigh rle...@codelibre.net writes:

 On Fri, Nov 19, 2010 at 04:40:57PM +0100, Goswin von Brederlow wrote:
 David Kalnischkies kalnischk...@gmail.com writes:
 
  On Thu, Nov 18, 2010 at 19:25, أحمد المحمودي 
  aelmahmo...@sabily.org wrote:
  On Thu, Nov 18, 2010 at 07:07:07PM +0100, Goswin von Brederlow wrote:
  And as discussed before policy disagrees with reality in this.
 
  Would you please elaborate ?
 
  Goswin likely refers to this thread: Buildd  binary-indep
  http://lists.debian.org/debian-devel/2010/09/msg00590.html
  Message-id: 20100924204433.ga4...@apache.rbscorp.ru
 
 
  Best regards
 
  David Kalnischkies
 
 And in short:
 
 Buildds install only Build-Depends but not Build-Depends-Indep but still
 call the build target. In reality the build target must work with
 only Build-Depends installed contrary to what policy says.

 I do hope this mess can be sorted out after squeeze is released.
 Mandating build-arch and build-indep would be a good thing, IMHO.
 It's not the buildd software that can change this though--the
 actual sticking point is dpkg-buildpackage, which is used by sbuild.

 sbuild is actually perfectly capable of installing Build-Depends-Indep
 and removing Build-Conflicts-Indep when invoked with the -A (build
 arch-all) option, but there are no buildds building arch-indep packages
 yet.  If we ever throw away uploaded binaries and build everything on
 buildds, this would then be useful.


 Regards,
 Roger

Don't count on it. This has been going on for years and years.

The simple solution is to just declare the build-indep/arch targets
required (maybe going via SHOULD to MUST) and then have
dpkg-buildpackage just use them when sources have changed (or just use
them and break things).

Unfortunately this would make a lot of packages instantly RC buggy so
people are afraid of doing that. And without mandating the targets and
making Build-Depends-Indep actually usefull there is no incentive for
maintainers to change the source.

But hey, all the maintainer has to do is add 1, in words ONE, char to
debian/rules. Just change build: to build%: and dpkg-buildpackage
could use build-arch/indep targets instead of build. Aparently that is
too much to ask.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87y68p6tcx@frosties.localnet

Re: Build-Depends-Indep, please review

[Boyd Stephen Smith Jr.]

In 87y68p6tcx@frosties.localnet, Goswin von Brederlow wrote:
Roger Leigh rle...@codelibre.net writes:
 On Fri, Nov 19, 2010 at 04:40:57PM +0100, Goswin von Brederlow wrote:
 David Kalnischkies kalnischk...@gmail.com writes:
  On Thu, Nov 18, 2010 at 19:25, أحمد المحمودي 
aelmahmo...@sabily.org wrote:
  On Thu, Nov 18, 2010 at 07:07:07PM +0100, Goswin von Brederlow wrote:
  And as discussed before policy disagrees with reality in this.
  
  Would you please elaborate ?
  
  Goswin likely refers to this thread: Buildd  binary-indep
  http://lists.debian.org/debian-devel/2010/09/msg00590.html
  Message-id: 20100924204433.ga4...@apache.rbscorp.ru
 
 Buildds install only Build-Depends but not Build-Depends-Indep but still
 call the build target. In reality the build target must work with
 only Build-Depends installed contrary to what policy says.
 
 I do hope this mess can be sorted out after squeeze is released.
 Mandating build-arch and build-indep would be a good thing, IMHO.
 
Don't count on it. This has been going on for years and years.

The simple solution is to just declare the build-indep/arch targets
required (maybe going via SHOULD to MUST) and then have
dpkg-buildpackage just use them when sources have changed (or just use
them and break things).

Unfortunately this would make a lot of packages instantly RC buggy so
people are afraid of doing that. And without mandating the targets and
making Build-Depends-Indep actually usefull there is no incentive for
maintainers to change the source.

But hey, all the maintainer has to do is add 1, in words ONE, char to
debian/rules. Just change build: to build%: and dpkg-buildpackage
could use build-arch/indep targets instead of build. Aparently that is
too much to ask.

I volunteer to make /this/ fix to any package that is unmaintained or whose 
maintainer is unresponsive, *if* Debian will change policy to /require/ build-
arch/indep and make dpkg-buildpackage use them instead of build sometime after 
the Squeeze release and before the Wheezy freeze.
-- 
Boyd Stephen Smith Jr.   ,= ,-_-. =.
b...@iguanasuicide.net   ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/


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

Re: Build-Depends-Indep, please review

[Charles Plessy]

Le Fri, Nov 19, 2010 at 01:30:00PM -0600, Boyd Stephen Smith Jr. a écrit :
 
 I volunteer to make /this/ fix to any package that is unmaintained or whose 
 maintainer is unresponsive, *if* Debian will change policy to /require/ build-
 arch/indep and make dpkg-buildpackage use them instead of build sometime 
 after 
 the Squeeze release and before the Wheezy freeze.

Nice to see enthousiasm ! Perhaps such project would make a good Debian
enhancement proposal (DEP, http://dep.debian.net/ )

Have a nice week-end,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101120005134.gh8...@merveille.plessy.net

Re: Build-Depends-Indep, please review

[Goswin von Brederlow]

Didier 'OdyX' Raboud did...@raboud.com writes:

 anatoly techtonik wrote:

 On Fri, Nov 5, 2010 at 10:02 AM, أحمد المحمودي 
 aelmahmo...@sabily.org
 wrote:
 Hello,

 I thought Build-Depends-Indep is for build-deps that are not needed by
 clean target.
 
 What is the meaning of name Build-Depends-Indep then? Dependencies
 that are required to build package, but from which clean rule is
 independent?

 No. Build-Depends-Indep lists the Build Dependencies needed to build the 
 architecture-INDEPendant packages.

 In short: your package must build the arch:any packages correctly when only 
 the Build-Depends are installed. It must be able to build also the arch:all 
 when the Build-Depends-Indep are also installed. This allows to have 
 minimal Build-Depends, while extending them with B-D-Indep (usually 
 documentation building tools) for the arch:all packages.

 All that is in Policy 7.7.

 Cheers, 

 OdyX

And as discussed before policy disagrees with reality in this.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8762vu1p6c@frosties.localnet

Re: Build-Depends-Indep, please review

[Goswin von Brederlow]

anatoly techtonik techto...@gmail.com writes:

 Hello,

 I've described situation around Build-Depends-Indep at
 http://wiki.debian.org/Build-Depends-Indep
 I hope it will be useful for people who are looking for description of
 this field. However, I am not expert in packaging, and some
 information is obviously missing. If you can fill the blanks, that
 would be awesome.

 Please, CC.

| As a result, it became possible to execute debian/rules with
| 'build-indep' and 'build-arch' targets correspondingly.

No, you can not, at least not in general. That is exactly the
problem. The build-indep and build-arch targets are optional and can't
be detected reliably. So dpkg-buildpackage has to call the build target
even if it only wants to build indep or arch packages. It is only
possible after you manually verified the package does have those
targets, which makes them rather useless.


The more usefull case is calling the binary-indep or binary-arch
targets, which then only depend on build-indep or build-arch
respectively. But since that then builds as (fake)root autobuilders
don't do that without having called build first.

| In practice I can't think of any real world example where this
| scenario can be used. The only useful application may be with
| autobuilders that build a lot of packages from scratch, i.e. in empty
| environment on different systems.

All autobuilders do exactly that. They only build the arch packages and
start from a clean chroot. Installing packages into the build chroot for
each build is a huge drain, esspecially for things like fonts that
get reindexed every time (those 'this might take a while' messages).


| Some people argue that 'build' not necessary calls 'build-indep' or
| 'build-arch', because policy says that it should call, not must
| call. I doubt that there are cases when 'build' doesn't call these -
| in this scenario some packages won't be built at all, just because
| autobuilders can't call anything, but 'build'.

I believe there are several cases. And autobuilders can build them just
fine. The secret is to have the binary-% targets depend on build-%
instead of build. The build targets itself can potentially do
nothing. That way build-indep and build-arch are called as needed
although at a later time and as (fake)root. It certainly isn't nice to
do this but it is the only way to make Build-Depends-Indep usefull.

Note: A less ugly case is having build depend on build-arch but not
build-indep. That way autobuilders build as normal user and only the
indep packges are build as (fake)root.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871v6i1olw@frosties.localnet

Re: Build-Depends-Indep, please review

[أحمد المحمودي]

On Thu, Nov 18, 2010 at 07:07:07PM +0100, Goswin von Brederlow wrote:
 
 And as discussed before policy disagrees with reality in this.
 
---end quoted text---

Would you please elaborate ?

-- 
 ‎أحمد المحمودي (Ahmed El-Mahmoudy)
  Digital design engineer
 GPG KeyID: 0xEDDDA1B7
 GPG Fingerprint: 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: Digital signature

Re: Build-Depends-Indep, please review

[David Kalnischkies]

On Thu, Nov 18, 2010 at 19:25, أحمد المحمودي aelmahmo...@sabily.org wrote:
 On Thu, Nov 18, 2010 at 07:07:07PM +0100, Goswin von Brederlow wrote:
 And as discussed before policy disagrees with reality in this.

 Would you please elaborate ?

Goswin likely refers to this thread: Buildd  binary-indep
http://lists.debian.org/debian-devel/2010/09/msg00590.html
Message-id: 20100924204433.ga4...@apache.rbscorp.ru


Best regards

David Kalnischkies


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktinkz2xpcgv=du�pcneuq4me5lrwx4p34ic...@mail.gmail.com

Re: Build-Depends-Indep, please review

[anatoly techtonik]

On Fri, Nov 5, 2010 at 10:02 AM, أحمد المحمودي aelmahmo...@sabily.org wrote:
 Hello,

  I thought Build-Depends-Indep is for build-deps that are not needed by
  clean target.

What is the meaning of name Build-Depends-Indep then? Dependencies
that are required to build package, but from which clean rule is
independent?
--
anatoly t.


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktikp9erdujqur8xsmhz1ueuma7r-puu4hn72t...@mail.gmail.com

Re: Build-Depends-Indep, please review

[Didier 'OdyX' Raboud]

anatoly techtonik wrote:

 On Fri, Nov 5, 2010 at 10:02 AM, أحمد المحمودي aelmahmo...@sabily.org
 wrote:
 Hello,

 I thought Build-Depends-Indep is for build-deps that are not needed by
 clean target.
 
 What is the meaning of name Build-Depends-Indep then? Dependencies
 that are required to build package, but from which clean rule is
 independent?

No. Build-Depends-Indep lists the Build Dependencies needed to build the 
architecture-INDEPendant packages.

In short: your package must build the arch:any packages correctly when only 
the Build-Depends are installed. It must be able to build also the arch:all 
when the Build-Depends-Indep are also installed. This allows to have 
minimal Build-Depends, while extending them with B-D-Indep (usually 
documentation building tools) for the arch:all packages.

All that is in Policy 7.7.

Cheers, 

OdyX


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ic14fk$h2...@dough.gmane.org

Re: Build-Depends-Indep, please review

[أحمد المحمودي]

Hello,

  I thought Build-Depends-Indep is for build-deps that are not needed by 
  clean target.

-- 
 ‎أحمد المحمودي (Ahmed El-Mahmoudy)
  Digital design engineer
 GPG KeyID: 0xEDDDA1B7
 GPG Fingerprint: 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: Digital signature

Re: Build-Depends-Indep and build target

[Goswin von Brederlow]

Florent Rougon [EMAIL PROTECTED] writes:

 Goswin von Brederlow [EMAIL PROTECTED] wrote:

 The underlying problem is that build-arch/indep are not mandatory and
 thus building must call the build target.

 This makes sense, thanks for pointing it out.

 If build-indep does take a considerable time then you can use the
 following hack:

 Indeed, it should work, but is rather ugly; I'd rather see Policy
 amended to make build-arch and build-indep mandatory.

 -- 
 Florent

The problem with that is that any package not having a build-* target
becomes instantly RC buggy. Some people are opposed to makeing that
big a spike in the RC graph. And DDs are too lazy to add the optional
build-* targets to prepare for them to become required.

Maybe after etch we could create enough of a group to force buil-*
targets in and damn the RC count. Let the buildds call build-arch and
fail any new upload without the targets and 6 month later fix the
stragglers. I don't see it as a problem to break things that way given
that the simple addition of '%' to the build target will fix the
problem for those too lazy to write build-arch/indep targets.

MfG
Goswin


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

Re: Build-Depends-Indep and build target

[Darren Salt]

I demand that Joachim Reichel may or may not have written...

 The underlying problem is that build-arch/indep are not mandatory and thus
 building must call the build target.

 Any chance that this will be changed for lenny? If build-arch and
 build-indep are optional and there is no reliable way to find out whether
 these targets exist [...]

This, perhaps?

  if make -f debian/rules -n build-arch; then
make -f debian/rules build-arch
  else
make -f debian/rules build
  fi

Then there's the problem of which targets (in the upstream makefile) should
be run from build-{arch,indep}. I don't see any obvious targets for splitting
up the building in this way in a typical automake-generated makefile (I
checked both xine-lib and gxine), which would appear to make
build-{arch,indep} pointless in this case, and would also provide an
explanation of why these targets are not mandatory.

[snip]
-- 
| Darren Salt| linux or ds at  | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Output less CO2 = avoid boiling weather. TIME IS RUNNING OUT *FAST*.

Mind your own business, Spock. I'm sick of your halfbreed interference.


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

Re: Build-Depends-Indep and build target

[Goswin von Brederlow]

Florent Rougon [EMAIL PROTECTED] writes:

 Hi,

 Joachim Reichel [EMAIL PROTECTED] wrote:

 Hi,

 section 7.6 of the policy states that Build-Depends-Indep must be
 satisfied if the build target is invoked.

 [...]

 Now, if my sponsor uploads this package, it will still fail, right? If
 Build-Depends-Indep is not satisfied by accident, the build will fail
 again ...

 Your analysis looks correct to me. It is a known fact that the buildds
 don't conform to Policy as far as Build-Depends and Build-Depends-Indep
 are concerned.

 So what should I do?

 I suggest you read the following post:

   http://lists.debian.org/debian-mentors/2006/09/msg00229.html

 The first paragraph by Wouter Verhelst (longtime buildd admin) tells you
 what buildds from real life expect, which explains why your build
 failed: because your Build-Depends line didn't contain all packages
 that are required for a 'dpkg-buildpackage -B' run to complete
 successfully (since, as you noticed, 'dpkg-buildpackage -B' does call
 'debian/rules build' and your 'build' target requires tetex-bin, which
 is not in your Build-Depends).

 The last paragraph, by Scott James Remnant, confirms this and tells you
 in a more straightforward way what you should do to have the package
 build successfully on the buildds: include tetex-bin in your
 Build-Depends, since it's needed in the 'build' target.

 But again, you're right on this: according to Policy, your package build
 should not fail due to latex being unavailable.

But on this point policy is wrong, in the sence of not reflecting the
long tradition of doing this the other way.

The underlying problem is that build-arch/indep are not mandatory and
thus building must call the build target.

If build-indep does take a considerable time then you can use the
following hack:

build: build-arch

build-arch:
# Build arch stuff

build-indep:
# Build indep stuff

binary: binary-arch binary-indep

binary-arch: build-arch

binary-indep: build-indep


Note that this will only build indep when needed on the plus side but
will build indep as (fake)root on the minus side.

MfG
Goswin


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

Re: Build-Depends-Indep and build target

[Florent Rougon]

Goswin von Brederlow [EMAIL PROTECTED] wrote:

 The underlying problem is that build-arch/indep are not mandatory and
 thus building must call the build target.

This makes sense, thanks for pointing it out.

 If build-indep does take a considerable time then you can use the
 following hack:

Indeed, it should work, but is rather ugly; I'd rather see Policy
amended to make build-arch and build-indep mandatory.

-- 
Florent


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

Re: Build-Depends-Indep and build target

[Joachim Reichel]

Hi,

 The underlying problem is that build-arch/indep are not mandatory and
 thus building must call the build target.

Any chance that this will be changed for lenny? If build-arch and
build-indep are optional and there is no reliable way to find out
whether these targets exist, what's the use? The logic behind it looks
flawed to me (in particular in combination with Build-Depends-Indep).

 If build-indep does take a considerable time then you can use the
 following hack:
[...]

Which is basically the same as moving the build-indep stuff to
binary-indep, and the build-arch stuff to build. Not nice, but maybe
worth the effort if build-indep takes much time.

On the other side, policy says that build should depend on build-arch
and build-indep (ok, just a should not a must).

Regards,
  Joachim


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

Re: Build-Depends-Indep and build target

[Florent Rougon]

Hi,

Joachim Reichel [EMAIL PROTECTED] wrote:

 Hi,

 section 7.6 of the policy states that Build-Depends-Indep must be
 satisfied if the build target is invoked.

[...]

 Now, if my sponsor uploads this package, it will still fail, right? If
 Build-Depends-Indep is not satisfied by accident, the build will fail
 again ...

Your analysis looks correct to me. It is a known fact that the buildds
don't conform to Policy as far as Build-Depends and Build-Depends-Indep
are concerned.

 So what should I do?

I suggest you read the following post:

  http://lists.debian.org/debian-mentors/2006/09/msg00229.html

The first paragraph by Wouter Verhelst (longtime buildd admin) tells you
what buildds from real life expect, which explains why your build
failed: because your Build-Depends line didn't contain all packages
that are required for a 'dpkg-buildpackage -B' run to complete
successfully (since, as you noticed, 'dpkg-buildpackage -B' does call
'debian/rules build' and your 'build' target requires tetex-bin, which
is not in your Build-Depends).

The last paragraph, by Scott James Remnant, confirms this and tells you
in a more straightforward way what you should do to have the package
build successfully on the buildds: include tetex-bin in your
Build-Depends, since it's needed in the 'build' target.

But again, you're right on this: according to Policy, your package build
should not fail due to latex being unavailable.

-- 
Florent


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

Re: Build depends....?

[Mihai Felseghi]

Thamk you all for the help, I will try to combine all the tricks  you
have teached me
Cheers.

Mihai Felseghi.

On 6/23/06, Justin Pryzby [EMAIL PROTECTED] wrote:

On Fri, Jun 23, 2006 at 01:51:14PM -0300, Nelson A. de Oliveira wrote:
 Hi!

 On 6/23/06, Mihai Felseghi [EMAIL PROTECTED] wrote:
   Hello dear mentors , please tell me if there is a method of finding
 the build depends for a piece of software (so i can fill the
 Build-Depends field of the control file)? I tried to use the script from
 New Maintainers Guide but it gave me no help.

 You can use a chroot to do this.
 A really nice too to check the build depends of your package is pbuilder.
 It creates a chroot and builds your package inside it.

 I will suggest to you take a look on pbuilder.
Note that the minimal build-dep set isn't the same as the full
build-dep set; if one build-dep directly or indirectly depends on
another direct build-dep, you could drop that direct build-dep, and
pbuilder would still compile.  But the suggestion is to list the full
build-deps, not the minimal set.  To find the full build-deps (which
will be a superset of the minimal build-deps) the following tools from
devscripts are suggested:

  - dpkg-depcheck, dpkg-genbuilddeps: determine the packages used during
  the build of a Debian package; useful for determining the Build-Depends
  control field needed [build-essential, strace]

Justin


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





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

Re: Build depends....?

[Nelson A. de Oliveira]

Hi!

On 6/23/06, Mihai Felseghi [EMAIL PROTECTED] wrote:

  Hello dear mentors , please tell me if there is a method of finding
the build depends for a piece of software (so i can fill the
Build-Depends field of the control file)? I tried to use the script from
New Maintainers Guide but it gave me no help.


You can use a chroot to do this.
A really nice too to check the build depends of your package is pbuilder.
It creates a chroot and builds your package inside it.

I will suggest to you take a look on pbuilder.

Regards,
Nelson


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

Re: Build depends....?

[Masami Ichikawa]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi.

on 06/24/06 01:48, Mihai Felseghi wrote:
   Hello dear mentors , please tell me if there is a method of finding
 the build depends for a piece of software (so i can fill the
 Build-Depends field of the control file)? I tried to use the script from
 New Maintainers Guide but it gave me no help.
  Thanks in advance !
 

Do you want to know like this?

[EMAIL PROTECTED]:~]% objdump -p /usr/bin/fluxbox | grep NEEDED
  NEEDED  libSM.so.6
  NEEDED  libICE.so.6
  NEEDED  libX11.so.6
  NEEDED  libXext.so.6
  NEEDED  libXft.so.2
  NEEDED  libfontconfig.so.1
  NEEDED  libXrender.so.1
  NEEDED  libXpm.so.4
  NEEDED  libXrandr.so.2
  NEEDED  libXinerama.so.1
  NEEDED  libstdc++.so.6
  NEEDED  libm.so.6
  NEEDED  libgcc_s.so.1
  NEEDED  libc.so.6
[EMAIL PROTECTED]:~]% dpkg -S libXrender.so.1
libxrender1: /usr/lib/libXrender.so.1
libxrender1: /usr/lib/libXrender.so.1.3.0
[EMAIL PROTECTED]:~]% apt-cache search libxrender
libxrender-dev - X Rendering Extension client library (development files)
libxrender1 - X Rendering Extension client library
libxrender1-dbg - X Rendering Extension client library (unstripped)
openoffice.org - OpenOffice.org Office suite version 2.0

I could find -dev package so, I can know fluxbox needs libxrender-dev.

Cheers.
- --
/*
 * Masami Ichikawa
 * mailto: [EMAIL PROTECTED]
 */
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEnCEnfCYcnwLjB2wRAqD0AJ4xLo85GnPexJ/EsDIfxofr6/0VywCfd5lO
4AT1gxI0b2rM0mD93k6m3+w=
=wi0M
-END PGP SIGNATURE-


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

Re: Build depends....?

[Mihai Felseghi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Masami Ichikawa wrote:
 Hi.
 
 on 06/24/06 01:48, Mihai Felseghi wrote:
   Hello dear mentors , please tell me if there is a method of finding
 the build depends for a piece of software (so i can fill the
 Build-Depends field of the control file)? I tried to use the script from
 New Maintainers Guide but it gave me no help.
  Thanks in advance !

 
 Do you want to know like this?
 
 [EMAIL PROTECTED]:~]% objdump -p /usr/bin/fluxbox | grep NEEDED
   NEEDED  libSM.so.6
   NEEDED  libICE.so.6
   NEEDED  libX11.so.6
   NEEDED  libXext.so.6
   NEEDED  libXft.so.2
   NEEDED  libfontconfig.so.1
   NEEDED  libXrender.so.1
   NEEDED  libXpm.so.4
   NEEDED  libXrandr.so.2
   NEEDED  libXinerama.so.1
   NEEDED  libstdc++.so.6
   NEEDED  libm.so.6
   NEEDED  libgcc_s.so.1
   NEEDED  libc.so.6
 [EMAIL PROTECTED]:~]% dpkg -S libXrender.so.1
 libxrender1: /usr/lib/libXrender.so.1
 libxrender1: /usr/lib/libXrender.so.1.3.0
 [EMAIL PROTECTED]:~]% apt-cache search libxrender
 libxrender-dev - X Rendering Extension client library (development files)
 libxrender1 - X Rendering Extension client library
 libxrender1-dbg - X Rendering Extension client library (unstripped)
 openoffice.org - OpenOffice.org Office suite version 2.0
 
 I could find -dev package so, I can know fluxbox needs libxrender-dev.
 
 Cheers.
 --
 /*
  * Masami Ichikawa
  * mailto: [EMAIL PROTECTED]
  */
 Thank you for the advice I will try this method.
Cheers.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEnFAec/YkXMGw+ooRAho8AJ4uWa//rDi7b+tZH1/eEev6E6wYUQCgklbt
/G6y/Gg9RQbIyE85eUIf6v0=
=ZUxS
-END PGP SIGNATURE-


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

Re: Build depends....?

[Stephen Gran]

This one time, at band camp, Mihai Felseghi said:
 Masami Ichikawa wrote:
  on 06/24/06 01:48, Mihai Felseghi wrote:
Hello dear mentors , please tell me if there is a method of finding
  the build depends for a piece of software
  
  [EMAIL PROTECTED]:~]% objdump -p /usr/bin/fluxbox | grep NEEDED

  Thank you for the advice I will try this method.

While that's a good start, it's a conflation of Depends and
build-Depends.  objdump is giving you runtime dependencies on shared
libraries, which are usually related to but not the same as the build
time dependencies.  There is a script in one of the new maintainer
documents that uses strace to look for open() calls in ./configure to
help you figure out build-dependencies.  Another method is to look at
all the #include'd headers your package needs, and figure out where they
come from.  Finally, use something like pbuilder to test your builds
when you think you're close - it will fail if you're missing something.
Also read the build logs from the pbuilder session very carefully to see
if it just disabled an optional feature rather than failed because you
missed something.

Take care,
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: Build depends....?

[Justin Pryzby]

On Fri, Jun 23, 2006 at 01:51:14PM -0300, Nelson A. de Oliveira wrote:
 Hi!
 
 On 6/23/06, Mihai Felseghi [EMAIL PROTECTED] wrote:
   Hello dear mentors , please tell me if there is a method of finding
 the build depends for a piece of software (so i can fill the
 Build-Depends field of the control file)? I tried to use the script from
 New Maintainers Guide but it gave me no help.
 
 You can use a chroot to do this.
 A really nice too to check the build depends of your package is pbuilder.
 It creates a chroot and builds your package inside it.
 
 I will suggest to you take a look on pbuilder.
Note that the minimal build-dep set isn't the same as the full
build-dep set; if one build-dep directly or indirectly depends on
another direct build-dep, you could drop that direct build-dep, and
pbuilder would still compile.  But the suggestion is to list the full
build-deps, not the minimal set.  To find the full build-deps (which
will be a superset of the minimal build-deps) the following tools from
devscripts are suggested:

  - dpkg-depcheck, dpkg-genbuilddeps: determine the packages used during
  the build of a Debian package; useful for determining the Build-Depends
  control field needed [build-essential, strace]

Justin


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

Re: Build-Depends-Indep and packages with architecture all

[Frank Kster]

Joel Baker [EMAIL PROTECTED] wrote:

 What concern do porters have with architecture-all-only-packages?

 With most Arch: all packages, little to none. The concern is actually in
 *not* having stuff that is *only* needed for -indep targets (which will
 generally never be built by porting machines) in the Binary-Depends field,
 so that it doesn't get installed (since it won't be needed). 

Ah, thank you, that's clear.

Bye, Frank
-- 
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie


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

Re: Build-Depends-Indep and packages with architecture all

[Frank Küster]

Joel Baker [EMAIL PROTECTED] wrote:

 What concern do porters have with architecture-all-only-packages?

 With most Arch: all packages, little to none. The concern is actually in
 *not* having stuff that is *only* needed for -indep targets (which will
 generally never be built by porting machines) in the Binary-Depends field,
 so that it doesn't get installed (since it won't be needed). 

Ah, thank you, that's clear.

Bye, Frank
-- 
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie

Re: Build-Depends-Indep and packages with architecture all

[Frank Kster]

Thomas Viehmann [EMAIL PROTECTED] wrote:

 Frank Küster wrote:
 In the original package's control file, there is a line of
 Build-Depends-Indep, but no Build-Depends. Does this make sense for a
 source package that has no architecture dependent binary packages at
 all? Why not just use Build-Depends here and use Build-Depends-Indep
 only when a source package yields both kinds of binary packages?

 If you hadn't asked here, I'd be inclined to think that you're looking
 for something beyond because that's what policy tells you to do (in
 the section on debian/rules)...

Either I don't understand your sentence, or I have a problem reading the
policy. In

file:///usr/share/doc/debian-policy/policy.html/ch-miscellaneous.html#s-debianrules

I can find statements about the targets binary-arch and binary-indep and
the respective build-targets. But there's nothing about
Dependency-fields in the control file. Also in Chapter 7, Declaring
relationships between packages, I cannot find an explanation (probably
because I didn't read thoroughly enough).

Bye, Frank
-- 
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie


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

Re: Build-Depends-Indep and packages with architecture all

[Frank Kster]

Joel Baker [EMAIL PROTECTED] schrieb:

 On Thu, Jul 31, 2003 at 04:54:42PM +0200, Frank Küster wrote:
 Hi,
 
 for practice and because I want to use it, I am working on a package of
 the CVS version of auctex, a LaTeX mode for Emacs. Since it's only an
 Emacs-addon written in Lisp, it's of course architecture independent. 
 
 In debian/rules of the real package from unstable, binary requires
 binary-arch and binary-indep; the first does nothing and the second
 builds the package.
 
 In the original package's control file, there is a line of
 Build-Depends-Indep, but no Build-Depends. Does this make sense for a
 source package that has no architecture dependent binary packages at
 all? Why not just use Build-Depends here and use Build-Depends-Indep
 only when a source package yields both kinds of binary packages?

 Because it is simpler to have two easily expressed rules (Build-Depends
 must be satisfied for X targets, Build-Depends-Indep must be
 satisfied for Y targets) than a complex set of exceptions
 (Build-Depends must be satisfied for X on Arch: (!= all), or Y on
 Arch: all, unless Build-Depends-Indep is also set, in which case)

That sounds sensible. However, I'm puzzled by the following statement in 

file:///usr/share/doc/debian-policy/policy.html/ch-relationships.html#s7.6

,
| Build-Depends, Build-Conflicts 
|
| The Build-Depends and Build-Conflicts
| fields must be satisfied when any of the following targets is invoked:
| build, clean, binary, binary-arch, build-arch, build-indep and
| binary-indep.
`

So if I put all the dependencies into Build-Depends for a package that
only generates a single package_version_all.deb, I get the same effect
as if I put only some (like debhelper) there and the rest into
Build-Depends-Indep. Or am I missing something?

 6 extra characters in the control file is a small price to pay for sanity,
 especially because it allows some of us (namely, porters) to build *simple*
 tools that figure out dependancy trees, and which can prune some parts of
 them based on this information.

What concern do porters have with architecture-all-only-packages?

TIA, Frank
-- 
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie


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

Re: Build-Depends-Indep and packages with architecture all

[Thomas Viehmann]

Hi.

Frank Küster ([EMAIL PROTECTED]) wrote:
Either I don't understand your sentence, or I have a problem reading the
policy. In
Or I was wrong. :)

file:///usr/share/doc/debian-policy/policy.html/ch-miscellaneous.html#s-deb
ianrules

I can find statements about the targets binary-arch and binary-indep and
the respective build-targets. But there's nothing about
Dependency-fields in the control file. Also in Chapter 7, Declaring
relationships between packages, I cannot find an explanation (probably
because I didn't read thoroughly enough).

Basically I thought that the explanation of binary-arch and binary-indep combined
with the principle of minimal build-dependencies yields the answer. Especially the
footnote in paragraph 7.6 (on package relations) seems to shed light on this (and
shead doubt on the effectiveness of build-depends-indep, oh well).

Cheers

T.


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

Re: Build-Depends-Indep and packages with architecture all

[Joel Baker]

On Fri, Aug 01, 2003 at 09:57:10AM +0200, Frank Küster wrote:
 Joel Baker [EMAIL PROTECTED] schrieb:
 
  On Thu, Jul 31, 2003 at 04:54:42PM +0200, Frank Küster wrote:
  Hi,
  
  for practice and because I want to use it, I am working on a package of
  the CVS version of auctex, a LaTeX mode for Emacs. Since it's only an
  Emacs-addon written in Lisp, it's of course architecture independent. 
  
  In debian/rules of the real package from unstable, binary requires
  binary-arch and binary-indep; the first does nothing and the second
  builds the package.
  
  In the original package's control file, there is a line of
  Build-Depends-Indep, but no Build-Depends. Does this make sense for a
  source package that has no architecture dependent binary packages at
  all? Why not just use Build-Depends here and use Build-Depends-Indep
  only when a source package yields both kinds of binary packages?
 
  Because it is simpler to have two easily expressed rules (Build-Depends
  must be satisfied for X targets, Build-Depends-Indep must be
  satisfied for Y targets) than a complex set of exceptions
  (Build-Depends must be satisfied for X on Arch: (!= all), or Y on
  Arch: all, unless Build-Depends-Indep is also set, in which case)
 
 That sounds sensible. However, I'm puzzled by the following statement in 
 
 file:///usr/share/doc/debian-policy/policy.html/ch-relationships.html#s7.6
 
 ,
 | Build-Depends, Build-Conflicts 
 |
 | The Build-Depends and Build-Conflicts
 | fields must be satisfied when any of the following targets is invoked:
 | build, clean, binary, binary-arch, build-arch, build-indep and
 | binary-indep.
 `

Hmmm. I'm not sure if that needs to be updated, or if I've just missed
something. Practice may be preceeding policy, however...

 So if I put all the dependencies into Build-Depends for a package that
 only generates a single package_version_all.deb, I get the same effect
 as if I put only some (like debhelper) there and the rest into
 Build-Depends-Indep. Or am I missing something?

It might work, given the above; it's still better style, if nothing
else, to use the BDI field for stuff that is needed when invoking the
build-indep/binary-indep targets (for example, latex2html or somesuch, for
generating docs for a foo-doc*_all.deb package)

  6 extra characters in the control file is a small price to pay for sanity,
  especially because it allows some of us (namely, porters) to build *simple*
  tools that figure out dependancy trees, and which can prune some parts of
  them based on this information.
 
 What concern do porters have with architecture-all-only-packages?

With most Arch: all packages, little to none. The concern is actually in
*not* having stuff that is *only* needed for -indep targets (which will
generally never be built by porting machines) in the Binary-Depends field,
so that it doesn't get installed (since it won't be needed). Or, in the
case of bootstrapping ports, so that they don't avoid building the package
thinking it needs emacs ported first, when really emacs is only used to do
some documentation fudging.

Yes, there are things in the archive which BDI on emacs...
-- 
Joel Baker [EMAIL PROTECTED]


pgp0.pgp
Description: PGP signature

Re: Build-Depends-Indep and packages with architecture all

[Frank Küster]

Thomas Viehmann [EMAIL PROTECTED] wrote:

 Frank Küster wrote:
 In the original package's control file, there is a line of
 Build-Depends-Indep, but no Build-Depends. Does this make sense for a
 source package that has no architecture dependent binary packages at
 all? Why not just use Build-Depends here and use Build-Depends-Indep
 only when a source package yields both kinds of binary packages?

 If you hadn't asked here, I'd be inclined to think that you're looking
 for something beyond because that's what policy tells you to do (in
 the section on debian/rules)...

Either I don't understand your sentence, or I have a problem reading the
policy. In

file:///usr/share/doc/debian-policy/policy.html/ch-miscellaneous.html#s-debianrules

I can find statements about the targets binary-arch and binary-indep and
the respective build-targets. But there's nothing about
Dependency-fields in the control file. Also in Chapter 7, Declaring
relationships between packages, I cannot find an explanation (probably
because I didn't read thoroughly enough).

Bye, Frank
-- 
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie

Re: Build-Depends-Indep and packages with architecture all

[Frank Küster]

Joel Baker [EMAIL PROTECTED] schrieb:

 On Thu, Jul 31, 2003 at 04:54:42PM +0200, Frank Küster wrote:
 Hi,
 
 for practice and because I want to use it, I am working on a package of
 the CVS version of auctex, a LaTeX mode for Emacs. Since it's only an
 Emacs-addon written in Lisp, it's of course architecture independent. 
 
 In debian/rules of the real package from unstable, binary requires
 binary-arch and binary-indep; the first does nothing and the second
 builds the package.
 
 In the original package's control file, there is a line of
 Build-Depends-Indep, but no Build-Depends. Does this make sense for a
 source package that has no architecture dependent binary packages at
 all? Why not just use Build-Depends here and use Build-Depends-Indep
 only when a source package yields both kinds of binary packages?

 Because it is simpler to have two easily expressed rules (Build-Depends
 must be satisfied for X targets, Build-Depends-Indep must be
 satisfied for Y targets) than a complex set of exceptions
 (Build-Depends must be satisfied for X on Arch: (!= all), or Y on
 Arch: all, unless Build-Depends-Indep is also set, in which case)

That sounds sensible. However, I'm puzzled by the following statement in 

file:///usr/share/doc/debian-policy/policy.html/ch-relationships.html#s7.6

,
| Build-Depends, Build-Conflicts 
|
| The Build-Depends and Build-Conflicts
| fields must be satisfied when any of the following targets is invoked:
| build, clean, binary, binary-arch, build-arch, build-indep and
| binary-indep.
`

So if I put all the dependencies into Build-Depends for a package that
only generates a single package_version_all.deb, I get the same effect
as if I put only some (like debhelper) there and the rest into
Build-Depends-Indep. Or am I missing something?

 6 extra characters in the control file is a small price to pay for sanity,
 especially because it allows some of us (namely, porters) to build *simple*
 tools that figure out dependancy trees, and which can prune some parts of
 them based on this information.

What concern do porters have with architecture-all-only-packages?

TIA, Frank
-- 
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie

Re: Build-Depends-Indep and packages with architecture all

[Thomas Viehmann]

Hi.

Frank Küster ([EMAIL PROTECTED]) wrote:
Either I don't understand your sentence, or I have a problem reading the
policy. In
Or I was wrong. :)

file:///usr/share/doc/debian-policy/policy.html/ch-miscellaneous.html#s-deb
ianrules

I can find statements about the targets binary-arch and binary-indep and
the respective build-targets. But there's nothing about
Dependency-fields in the control file. Also in Chapter 7, Declaring
relationships between packages, I cannot find an explanation (probably
because I didn't read thoroughly enough).

Basically I thought that the explanation of binary-arch and binary-indep 
combined
with the principle of minimal build-dependencies yields the answer. Especially 
the
footnote in paragraph 7.6 (on package relations) seems to shed light on this 
(and
shead doubt on the effectiveness of build-depends-indep, oh well).

Cheers

T.

Re: Build-Depends-Indep and packages with architecture all

[Thomas Viehmann]

Frank Küster wrote:
 In the original package's control file, there is a line of
 Build-Depends-Indep, but no Build-Depends. Does this make sense for a
 source package that has no architecture dependent binary packages at
 all? Why not just use Build-Depends here and use Build-Depends-Indep
 only when a source package yields both kinds of binary packages?
If you hadn't asked here, I'd be inclined to think that you're looking for
something beyond because that's what policy tells you to do (in the section on
debian/rules)...

Cheers

T.


pgp0.pgp
Description: PGP signature

Re: Build-Depends-Indep and packages with architecture all

[Joel Baker]

On Thu, Jul 31, 2003 at 04:54:42PM +0200, Frank Küster wrote:
 Hi,
 
 for practice and because I want to use it, I am working on a package of
 the CVS version of auctex, a LaTeX mode for Emacs. Since it's only an
 Emacs-addon written in Lisp, it's of course architecture independent. 
 
 In debian/rules of the real package from unstable, binary requires
 binary-arch and binary-indep; the first does nothing and the second
 builds the package.
 
 In the original package's control file, there is a line of
 Build-Depends-Indep, but no Build-Depends. Does this make sense for a
 source package that has no architecture dependent binary packages at
 all? Why not just use Build-Depends here and use Build-Depends-Indep
 only when a source package yields both kinds of binary packages?

Because it is simpler to have two easily expressed rules (Build-Depends
must be satisfied for X targets, Build-Depends-Indep must be
satisfied for Y targets) than a complex set of exceptions
(Build-Depends must be satisfied for X on Arch: (!= all), or Y on
Arch: all, unless Build-Depends-Indep is also set, in which case)

6 extra characters in the control file is a small price to pay for sanity,
especially because it allows some of us (namely, porters) to build *simple*
tools that figure out dependancy trees, and which can prune some parts of
them based on this information.
-- 
Joel Baker [EMAIL PROTECTED]


pgp0.pgp
Description: PGP signature

Re: Build-Depends-Indep and packages with architecture all

[Thomas Viehmann]

Frank Küster wrote:
 In the original package's control file, there is a line of
 Build-Depends-Indep, but no Build-Depends. Does this make sense for a
 source package that has no architecture dependent binary packages at
 all? Why not just use Build-Depends here and use Build-Depends-Indep
 only when a source package yields both kinds of binary packages?
If you hadn't asked here, I'd be inclined to think that you're looking for
something beyond because that's what policy tells you to do (in the section on
debian/rules)...

Cheers

T.


pgp6vQiLwmKvi.pgp
Description: PGP signature

Re: Build-Depends-Indep and packages with architecture all

[Joel Baker]

On Thu, Jul 31, 2003 at 04:54:42PM +0200, Frank Küster wrote:
 Hi,
 
 for practice and because I want to use it, I am working on a package of
 the CVS version of auctex, a LaTeX mode for Emacs. Since it's only an
 Emacs-addon written in Lisp, it's of course architecture independent. 
 
 In debian/rules of the real package from unstable, binary requires
 binary-arch and binary-indep; the first does nothing and the second
 builds the package.
 
 In the original package's control file, there is a line of
 Build-Depends-Indep, but no Build-Depends. Does this make sense for a
 source package that has no architecture dependent binary packages at
 all? Why not just use Build-Depends here and use Build-Depends-Indep
 only when a source package yields both kinds of binary packages?

Because it is simpler to have two easily expressed rules (Build-Depends
must be satisfied for X targets, Build-Depends-Indep must be
satisfied for Y targets) than a complex set of exceptions
(Build-Depends must be satisfied for X on Arch: (!= all), or Y on
Arch: all, unless Build-Depends-Indep is also set, in which case)

6 extra characters in the control file is a small price to pay for sanity,
especially because it allows some of us (namely, porters) to build *simple*
tools that figure out dependancy trees, and which can prune some parts of
them based on this information.
-- 
Joel Baker [EMAIL PROTECTED]


pgp0LRl47QBea.pgp
Description: PGP signature

Re: Build-Depends on source of a different package?

[Sven Luther]

On Wed, Feb 26, 2003 at 01:17:13PM +0100, Andreas Metzler wrote:
 Hello,
 Is there a right way for using the source of a different
 debian-package?

For ocaml, i supply an ocaml-source package for other folk to use it.

 I've checked the archives, but I only found 
 http://lists.debian.org/debian-mentors/2001/debian-mentors-200103/msg00253.html
 which is a little bit dated and without really positive outcome. The
 best suggestion was something similar to
 if [ ! -e $TMPDIR/foo.tar.gz ]; then
pushd $TMPDIR
apt-get source --tar-only foo
popd
 fi
 
 If you're wondering: The package in question would be exim v4 with the
 exiscan patch applied. - It cannot simply be built from the exim4
 source-package because the patch is released more often than exim
 itself (current-version is already 4.12-24).

Well, why don't you simply do a package with a copy of the exim sources,
and add the patch in the .diff.gz. This way you upload the source just
once, and upload new .diff.gz each time there is a new version of the
patches ?

Friendly,

Sven Luther


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

Re: Build-Depends on source of a different package?

[Andreas Metzler]

On Wed, Feb 26, 2003 at 01:42:21PM +0100, Sven Luther wrote:
 On Wed, Feb 26, 2003 at 01:17:13PM +0100, Andreas Metzler wrote:
 Is there a right way for using the source of a different
 debian-package?
 
 For ocaml, i supply an ocaml-source package for other folk to use it.

Hello,
That's the easiest possibility, but it sucks bandwith-wise. -
exim4_source-4.12-5 and exim4_source-4.12-8 can be identical (I
probably have only changed/debian), nevertheless I'll have to upload
it.

 I've checked the archives, but I only found 
 http://lists.debian.org/debian-mentors/2001/debian-mentors-200103/msg00253.html
  which is a little bit dated and without really positive outcome. The
 best suggestion was something similar to
 if [ ! -e $TMPDIR/foo.tar.gz ]; then
pushd $TMPDIR
apt-get source --tar-only foo
popd
 fi
 
 If you're wondering: The package in question would be exim v4 with the
 exiscan patch applied. - It cannot simply be built from the exim4
 source-package because the patch is released more often than exim
 itself (current-version is already 4.12-24).
 
 Well, why don't you simply do a package with a copy of the exim sources,
 and add the patch in the .diff.gz. This way you upload the source just
 once, and upload new .diff.gz each time there is a new version of the
 patches?

But I'd have to reupload all the packages not influenced by the
exiscan-patch at all (-base, -daemon-light, -daemon-heavy) just for
a new release of the exiscan-patch.

Real reason: I don't want the exiscan-patch in the exim4 source
package because I won't be using it and don't want to maintain it.
It will likely have bugs not influencing exim at all and these bugs
shouldn't influence exim's progress to testing.
   cu andreas


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

Re: Build-Depends on source of a different package?

[Andreas Metzler]

Hello,
I'd like to move this discussion to the exim4debian ml.

On Wed, Feb 26, 2003 at 02:23:41PM +0100, Simon Richter wrote:
 If you're wondering: The package in question would be exim v4 with the
 exiscan patch applied. - It cannot simply be built from the exim4
 source-package because the patch is released more often than exim
 itself (current-version is already 4.12-24).
 
 Hrm, what does it need the patch for. I can understand that
 configuration file changes might be needed, but a patch?

The way exim is designed adding new configuration-variables to the
config-file requires patching the source.

Crosschecking againsts exim-sa: it should be possible to change exiscan
to use its own configfile instead.

 Would it be possible (in cooperation with upstream) to split the
 package into stuff that can be applied upstream, does not change
 often and can be optionally switched on an off (stable API) and
 stuff that changes often and thus should not be compiled directly
 into a mission critical piece of software anyway?

I've browsed over the patch and didn't actually try to understand that
but my educated _guess_ is that the exiscan-patch basically copies the
whole local_scan interface to a new name exiscan. The real
functionality is then in exiscan.c.

It might be possible to let the real exiscan-code be dlopened similar
to Marc Merlin's dlopen-patch for local_scan

 Since there will probably be multiple exim packages, this would
 effectively double their number again (exim4-tls-ldap-noexiscan, sigh).
 So it would be better to have a real virus scanner API and make exiscan
 plug into that instead of inventing workarounds for broken design.

This argument strikes me as a strong one.
cu andreas


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

Re: Build-Depends on source of a different package?

[Sven Luther]

On Wed, Feb 26, 2003 at 02:15:11PM +0100, Andreas Metzler wrote:
 On Wed, Feb 26, 2003 at 01:42:21PM +0100, Sven Luther wrote:
  On Wed, Feb 26, 2003 at 01:17:13PM +0100, Andreas Metzler wrote:
  Is there a right way for using the source of a different
  debian-package?
  
  For ocaml, i supply an ocaml-source package for other folk to use it.
 
 Hello,
 That's the easiest possibility, but it sucks bandwith-wise. -
 exim4_source-4.12-5 and exim4_source-4.12-8 can be identical (I
 probably have only changed/debian), nevertheless I'll have to upload
 it.

Yes, sure, in my case, i don't like ocaml-source, and i am not the one
using it.

  I've checked the archives, but I only found 
  http://lists.debian.org/debian-mentors/2001/debian-mentors-200103/msg00253.html
   which is a little bit dated and without really positive outcome. The
  best suggestion was something similar to
  if [ ! -e $TMPDIR/foo.tar.gz ]; then
 pushd $TMPDIR
 apt-get source --tar-only foo
 popd
  fi
  
  If you're wondering: The package in question would be exim v4 with the
  exiscan patch applied. - It cannot simply be built from the exim4
  source-package because the patch is released more often than exim
  itself (current-version is already 4.12-24).
  
  Well, why don't you simply do a package with a copy of the exim sources,
  and add the patch in the .diff.gz. This way you upload the source just
  once, and upload new .diff.gz each time there is a new version of the
  patches?
 
 But I'd have to reupload all the packages not influenced by the
 exiscan-patch at all (-base, -daemon-light, -daemon-heavy) just for
 a new release of the exiscan-patch.

Mmm, you would not include the patch into the official exim4 package,
but have a copy of the exim4 package (exim4-exiscan), which will only
produce the -exiscan package, and replace/provide/divert/whatever the
corresponding package in the exim4 packages. Sure, you would have two
copies of the exim4 sources in the archive, and you would have to
coordinate the changes in both of them, but it is a good solution to the
above problems. I don't know of another way of doing this.

 Real reason: I don't want the exiscan-patch in the exim4 source
 package because I won't be using it and don't want to maintain it.
 It will likely have bugs not influencing exim at all and these bugs
 shouldn't influence exim's progress to testing.

See above ...

Friendly,

Sven Luther


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

Re: Build-Depends on source of a different package?

[Matt Zimmerman]

On Wed, Feb 26, 2003 at 01:17:13PM +0100, Andreas Metzler wrote:

 Is there a right way for using the source of a different
 debian-package?

Look into apt-src if you are interested in developing this kind of idea.
The source-dependency approach has many pitfalls, and is not something that
is supported in prime-time Debian right now.

If the source is small, it may be acceptable to duplicate it (especially if
it must stay in sync with a particular version).  In other cases, it makes
more sense to have the existing package build multiple flavours.  In still
other cases, it makes sense to have a -source package and have users build
their own.

-- 
 - mdz


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