Re: suse open build service - debian builds

[gbWilly <gbWilly@xxxxxxxxxxxxxx>]

On Wednesday, December 11th, 2024 at 14:42, T Lee Davidson <t.lee.davidson@xxxxxxxxx> wrote:

> gbWilly, your post containing the content quoted below was much more clear and comprehendible. Thank you.
> 
> 
> I was not asking you to explain to me what tools to use to effect a build. It simply seemed to me that you were making things
> more complicated than necessary. And, that is why I was asking questions.
> 
> Case in point:
> 
> On 12/10/24 16:00, gbWilly wrote:
> 
> > > And so, greatly simplified, you unpack the original source, repack it with `dpkg-source`, and then unpack it again ... all
> > > before executing `dpkg-buildpackage` and all just to get the .dsc file. Correct?
> 
> > Nope, I unpack original source, add recipe and use dpkg-source -b to create a source archive that I can unpack and dpkg-buildpackage can build
> > The .dsc for me is a byproduct I do NOT need nor does dpkg-buildpackage
> > osb wants the .dsc file
> 
> 
> That sounds just the same as what I said.
> Step 1: Unpack the original source and add the 'debian' directory to the source tree
> Step 2: Repack the source tree into a source archive
> Step 3: Unpack the source archive created in Step 2 into a source tree for use by dpkg-buildpackage
> 
> ... unpack, repack, and unpack again.
> 
> I suspect you are using Step 2 to force the source to be in Native format when it actually should be Quilt as the 'debian'
> directory is not contained in the pristine tarball. To my mind, Step 2, which unnecessarily creates the need for Step 3, is an
> unnecessary complication.
> 
> But it's no matter. Do as you like.

Well, a quilt build wants source, debian recipe as separate entities, to put them together for dpkg-buildpackage to be able to do it's magic

> And, yes, dpkg-source is invoked by dpkg-buildpackage, but, as you probably know, that can be disabled by passing to it the 'b'
> ("binaries only") option: `dpkg-buildpackage -b`.

Yes, I always invoke the -b option, but osb seems not to. But of no matter anymore as Benoit got it up and running...

But, if I want to do a quilt build (and I have done many --> my downloadable file repo's on gitlab are all quilt builds) I have to:

1. unpack source
2. copy debian folder (recipe) into source

--> now I can package, not a moment sooner
But, since, I package on vm, I make an archive with tar of above, just for sake of easy transport to vm.
If I try dpkg-source -b on above source with quilt recipe it will fail.

For native I do (but with a native recipe).

1. unpack source
2. copy debian folder (recipe) into source

--> now I can package, not a moment sooner
Instead of tar I can now use dpkg-source -b to do the job for me (as I have automated my recipe build to deliver me a package-able and transportable archive using dpkg-source)

So, not that much difference from my perspective if I want something dpkg-buidpackage understands to build from that I can transport.
In both cases I end up with a source archive with recipe included (for transport and storage sake -> yes I keep old builds)

And the unpacking is in a vm, so I can immediately start building packages with dpkg-buildpackages.
So, yes unpack (source), repack (source with recipe for transport), and unpack (package on a vm) again...

On a side note:
git-buildpackage does above using git, so getting source from git, recipe from git and set all up for dpkg-buildpackage. Now if you can run that from a vm then there is no need for an archive as long as git has  an unpacked source folder with recipe it will package. Look at gambas3 on debian salsa, they have gambas3 source and a debian folder in their source. 

So, a debian maintainer for gambas3 syncs their salsa (custom debian gitlab) with some tag on our gitlab, works at the recipe, tests it probably if it builds locally, and next do a build request. Simple as that, no packing, unpacking... Now git-buildpackage has all it needs. As they always build for sid, no different recipes are needed. From here on all is fully automated packaging on many different architectures and online reporting on the different builds.

It is possible, since they do it. They even build special tools (git-buildpackage) and infrastructure (salsa) for their maintainers.
)

> 
> Thank you for your responses to my queries. And, thank you very much for all your hard work on this project.

Thank you for asking, it helps me improve my understanding of the matter as well, by trying to explain it to others.
And thank you for your kind words

gbWilly