Hello,

I already read a few times the page on the DEB_BUILD_PROFILES [1] but I still don't really get it on how it actually works when one package has a self dependency.

I have a package, let's name it "src-pkg", that needs to be built first to create the binary package, let's name it "bin-pkg-A".

Once this "bin-pkg-A" is ready, I have to build another binary package (still from src-pkg but with other configure options) that would be named "bin-pkg- B".

In the end, both binary packages are to be available, because "bin-pkg-B" will depend on "bin-pkg-A".

For now, I proceed with 2 runs of dpkg-buildpackage, each with its own DEB_BUILD_PROFILES value. This will produce 2 *.changes files.

Is it possible to have both of them built in one single dpkg-buildpackage run and produce a single *.changes file containing everything?

How does is this actually managed on the official buildd servers? How does it actually know which DEB_BUILD_PROFILES to apply on each run?

Thank you
Fab

[1]: https://wiki.debian.org/BuildProfileSpec

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Sep 16, 2022 at 07:53:57PM +0200, Fab Stz wrote:

Hello,

I already read a few times the page on the DEB_BUILD_PROFILES [1] but I still
don't really get it on how it actually works when one package has a self dependency.

I have a package, let's name it "src-pkg", that needs to be built first to create the binary package, let's name it "bin-pkg-A".

Once this "bin-pkg-A" is ready, I have to build another binary package (still
from src-pkg but with other configure options) that would be named "bin-pkg- B".

Why do you need bin-pkg-A for this? You already build it during the same
build process. Do you 100% need the files installed into the system
locations?

--
WBR, wRAR

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmMkvPotFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh OTMP/iHUsE5dQOLkmuQv0xr7t6avusEEVIefPdMP5YLQzGksl6TpVsP+YVEsjmmX xFVLsTD/vdhWuTgXxAc2CR5Ktp3yiKNPLQ+emnaLIEOPIwooolTbqYPP/hUh8OXh JYJ6e0eLYODhZx7QtddTuSIPNShX6Qv4iiISrhvsqAksusWVznOF9QKD6uoCoJPs +f2bDFNGeT/wMAwLDUph2TKAxxM+Yr89qGCzTqPy6MRny0zfEp3f1r9pSbQBTV/g OOsr7Ei12DvzjxShbF6pMS11ShgFwE/4rGAgEUJJUkrvNBI1r4Sv7O89LZyTacK0 0ymnZl4Hbdxj5DsoFSMhOjwN98ZEVY/soaxOQQgMwaLah2hEUFPQy+L0M0pf2Hde BuQrGggqERdL/hrgYWQKqIKIkXpF7kGKLC2mOAjZS9lp/usNxXNRFgOHO4mt64jO 0XAlZZLbQXduB9isqB88hjDJaqFJ5Mj1AXhcxiGuUrahzrAQBh2+iRGQm4LoJU3A r2f6cOur+R7nY77/qjH41eowF7FJIfkml8YQnwARn1guhnwRYAn3DA/b4f1UMAZP u1C+O4gzQqlW3wSDSDtRtKa+LaGb1uw2TYMIzWVOLM8OH/juvJQtDTef9xKpfjnk avJ2asKjsev70heYApJOHb+4E7Cag2ztyxR6Pct5d4rbog3V
=LQqc
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 2022-09-16 at 19:53 +0200, Fab Stz wrote:

How does is this actually managed on the official buildd servers? How
does it actually know which DEB_BUILD_PROFILES to apply on each run?

The Debian buildds currently do not have support for build profiles,
for now build profiles are only for bootstrappers/porters/maintainers.

It sounds like you are going to have to fix the upstream build system
to use the first build products during the second build product build.

--
bye,
pabs

https://wiki.debian.org/PaulWise

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAmMlMA0ACgkQMRa6Xp/6 aaNQoBAAkTpEfDS+2pqSQqbUkuiKZmh5fagyKsCySVT0gep/0hLnA2szL0yrn02f djx6tGVajRtiFXtSxAjTkmP9Hh8Wtv50bCeZLAuAwDzeAMnR8HHHT5lDgHyf2fXL ClqHKZDDvcNLzNC690+vILXuMiXvDgTGYcf/1Lwc0vaJZz577MGkcftz/b8M9IBD xdUs8/YSlfoNS8nH2LlWDmAlMe0qCqsWCNCA9WBu1Qj9C3I2C+NTwYVEkn7XmutM Ww2Uv8a6bQl1LilM2eclf0fFC+pHJTpXsCC4i0JI8pr3TOOIGa9RGDQwy972zfC2 2Z4NtkuqRgHZ+x/rK3xH3tFNZLO+MJRuZ8Pko7npJ3fG7qFMtQ/uLr4cN2+1zlbY dMsxgPNeWf1xIiGohdKmIqrOCSfUlhxokgdx9wJSyVYIC5LFG0Fz7caZKke3uQ0r mggxW+dp3QY3mjHCaCHEm9AZNst4MBvajRuE3/O9x9e2Wbt4bOHD4968aDB9gKSr Lkmw7bn2HTPpvQZE6Y+pLnHR2ZUVC1EQrW76oMJRdBUOarzyW04qUAk/DoUt8i7E nmDhnf6Nhz0goq/8Th6PYfFKndCs6OBuLNyUKptDRFVzU1bUoiqCzs4BspBBHZrD SyfzXHODX85HDJ0FyNndax0nq8OfbgXujcf/iz0gZ3kTluwobsI=
=Et+D
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-09-17 10:25 +0800, Paul Wise wrote:

On Fri, 2022-09-16 at 19:53 +0200, Fab Stz wrote:

How does is this actually managed on the official buildd servers? How
does it actually know which DEB_BUILD_PROFILES to apply on each run?

The Debian buildds currently do not have support for build profiles,
for now build profiles are only for bootstrappers/porters/maintainers.

It sounds like you are going to have to fix the upstream build system
to use the first build products during the second build product build.

As Paul says, build profiles will not help here if you have to do this
_every time_ you build the package, as opposed to doing it once, then
using that to build the real package the first time in order to get it
ready for the archive. i.e. build profiles are for bootstrapping, and the results do not end up in the archive.

The normal way to fix this in Debian is for the debian build to run
the build twice, using the components built on the first run for the
second run. Can you do this easily, or do they have to be installed in
system paths to work?

You can also have the debian build run the build twice, one producing
pkg-A and one producing pkg-B, so that both end up in the
archive. Binutils is an example of a package that does this (building
both native and cross versions).


Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEER4nvI8Pe/wVWh5yq+4YyUahvnkcFAmMljAMACgkQ+4YyUahv nkdfuQ/9Erc0XPjn4y8HgmW2yf4lhhn7hu2/CekSj7vB9oInQjCkd9sEV519EtT/ BD1Y2F2wnoZakUf/VLf/n4kqoufiNyOGpaR85gX8bkFXWvv1LiULohQBxUM+IwTg /2V/NuiRTG8/PXZjVl4fQLhvANST9EKeCHL9Ave04hIlSpYAiOB7PRVa/ACR4fbq 4BCPgdHqJyjNusbe/lGQCKqRQXWFh1ZeopcEsNLBrCjidocqhuBlvUdNaG241vAv 3OsPGDV7Q+NsiMFQgAOzBh3r9iaHxxYdairCr2X1JCbR2/m1NRZAPOAG/SYVuyUi tc4yGRkkx3PjTl+5ieblfyZczBdZs9DuXuIihzmpel+C9HZsKi+0mBs2M1Js1Swq 4l7/+hWOY1X+c6m5UWztZqgcXWgcLYNIH5sSCHr/n8dwJyIEuQ7Jher2KpDp8Rqb yAqCQXAXUoydSdenFCAKEw9GtzGwI7Jlj9DzhKP//VLNemenKriPtZR1fZnzQPLH Rx51ioMm7IYgahK6qCG+Dlsa95b2jpBFBvpEG8P0kgbmYOydVrelyUeloh2d3qXj SNjzTBIUO9Plj4MzkZ0AmAcrDkrHgd3q8PmXr7T7ImcAqVjnzACuiu+RnsVHAvIL Do8dDsfVYMaASIbjNYcFgC7SfhvQDRVyDvocClVSf+yJVClvbj4=
=92ER
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Wookey,

As Paul says, build profiles will not help here if you have to do this
_every time_ you build the package, as opposed to doing it once, then
using that to build the real package the first time in order to get it
ready for the archive. i.e. build profiles are for bootstrapping, and the results do not end up in the archive.

The normal way to fix this in Debian is for the debian build to run
the build twice, using the components built on the first run for the
second run. Can you do this easily, or do they have to be installed in
system paths to work?

You can also have the debian build run the build twice, one producing
pkg-A and one producing pkg-B, so that both end up in the
archive. Binutils is an example of a package that does this (building
both native and cross versions).

Ok I just tried this by adding dependent targets in d/rules. It was a bit tricky to do so as to still use dh at the same time but it seems to work. Thanks for putting me on the way.

However, what is actually the difference between the two alternatives you mention? Build twice vs build twice the binutils way ?

The d/rules actually configures/builds first the host-build, which I'm able to use directly in the configuration parameters when configuring/building the android-build (which is the second build performed automatically).
In the end, this produces pkgA & pkgB binary packages all with a single dpkg- buildpackage run.

Rgds
Fab

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-09-20 13:20 +0200, Fab Stz wrote:

Ok I just tried this by adding dependent targets in d/rules. It was a bit tricky to do so as to still use dh at the same time but it seems to work. Thanks for putting me on the way.

However, what is actually the difference between the two alternatives you mention? Build twice vs build twice the binutils way ?

The distinction I was making was
a) build twice but only put the final build in a binary package
b) build twice and make two debian packages

The d/rules actually configures/builds first the host-build, which I'm able to
use directly in the configuration parameters when configuring/building the android-build (which is the second build performed automatically).
In the end, this produces pkgA & pkgB binary packages all with a single dpkg- buildpackage run.

OK. But do people really need both packages in the archive? Or is only the pkgB actually useful?

Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEER4nvI8Pe/wVWh5yq+4YyUahvnkcFAmMpwLoACgkQ+4YyUahv nkeZuQ/+ILN33YnsKBPOAKgloq14nU+T5JJY1DSKY8Bdxu9fSOEjzeww+mvOQwZQ JgnjaoTqrvQb69tqxXzbnUW5v4ScWuVPPN8T5FuiYdKi5b/SUWZCQ61+/cJF+EoJ UurKoNuwUj2oOJ/mQ9Rk3QYKybxOxRm5EqNSmTYuoMRUVCvUOiLuYiGBZby4JqIQ O16+VLDjJeyRKOj06wleU5vNCPn5K2qHomokmdX6vNIoz9NpWdzLtX27Vf7F9NeI XTmdDa3bXWIA0Zl5OpCKklBsRKsETe09xIm71l1xme1CyD0U6K34nD5km/P6Ou+0 IFnrPS989BraHO+UoL7UVPSSy0ea+rdBAPCGo3VVW/VUpUss2ckGPrtYcv4B02IB /7lvrnqZtEhXkrOYItX5/OJ2C7hSdz/R1EUaAE3L15m38nPs/O998++Cw6+XBw3W s6wojrr1eiDmFxDWw8Ul19QZfEBUk4CssBPgnEyZluTkJYRSbORUapH0D82XxOmt CHmGGlEuY7+fnJzKLfCcaATdErDBTKGomF+3/VO1w+DXh1w9Xavb82lFVlTkdnfz KXFtW6yiXjUi9sw8BWJmf7zgoSY0cCn0oXdh6hZWXTliAdbjr3sPa2A4cB3HXTeB h1vZpL6Njr4iNi41UMlI1FB9a1KpP+MJs3dA/aDdRFK4Uc4/7Ns=
=MzCy
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Sep 20, 2022 at 01:20:19PM +0200, Fab Stz wrote:

Ok I just tried this by adding dependent targets in d/rules.

You don't really need "dependent targets in d/rules" for this, just making
sure both builds run from the usual dh targets. In many cases this is done
by calling two build commands from override_dh_auto_build.

The d/rules actually configures/builds first the host-build, which I'm able to
use directly in the configuration parameters when configuring/building the android-build (which is the second build performed automatically).

Good, so the thing you said isn't possible is actually possible? Then it
solves the original problem.

--
WBR, wRAR

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmMpx74tFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh QJUQAJ/wLSOC58yEw0vtAAS8QZMCEXLrmWUFr9pSNZJa0VCFirgo1T4fOgr5K73T g18VmCjxBSJhR/Awj+oh2aAjBUeQ1pgK2J2EmiqGvtWSEL8kgaOAst4LySriEIH0 kgGUDPG5MmpAUtlAPv/Sndk4pT9iJBNt6kXwHCmQTPuNxnSuiXEg5ndM8q8TuVf2 h1NNy5TT1uQOa3ba0m7VmpQDQi1Z8M6GwhlkYAnrIkALTF8AJR4JA3g4Csvu/541 SYUTzHsQD4RR2aZrgbjlUTJe2X2hiYf4zM+ZWpGfgvqXxNE8A/dG1uPbedrGfjWJ le26xmEF38mIsT8KABhnY6nI+y5YW0+Uzah20mbgwgbhzrjS1aGYnaI9IH7/ARtB 37JLMMPRceIo5nQt+Xb2ePbLcWEqD1RQxr9Y/xZhE7H5jUNvUIgnnTFylCyjgTrR Cm/ZyruQX+Fhj+8m6zOf7dsn5XifWp/D/P+pXaA3IywNtFwuDTQBpsFYRrJoyVIA +IpGBBrTJMkIdklAMd/mjLD8QMEHIhIV+7geCE8fXyhyqYm+EiAsP+UGE70LVIHa CY7c1JMGmfRPCJEgcU9KWa8c7zcUleTkxlq4/So4DozZtqZCihRvwOmjD99s6E/R U1o9Km9nJxvSRMqtxuO63Oi2yaJ1lgB4NR4yZfY4OGjc3gug
=lkwz
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

The d/rules actually configures/builds first the host-build, which I'm
able to use directly in the configuration parameters when configuring/building the android-build (which is the second build
performed automatically). In the end, this produces pkgA & pkgB binary packages all with a single dpkg- buildpackage run.

OK. But do people really need both packages in the archive? Or is only the pkgB actually useful?

The package in question is Qt. For example qt6-base. So there are the regular qt6 packages that are already in the archive, and I wanted to provide also the "Qt for Android" packages based on the same source but cross-compiled for Android which is required to build android apps that use the Qt framework.

If you are interested, I just made a MR here https://salsa.debian.org/qt-kde-team/qt6/qt6-base/-/merge_requests/14

Rgds

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)