Re: [gambas-package-config] Automatic generation of OBS configuration

[gbWilly <gbWilly@xxxxxxxxxxxxxx>]

On Tuesday, December 3rd, 2024 at 02:03, Benoît Minisini benoit.minisini@xxxxxxxxxxxxxxxx wrote:

> Le 03/12/2024 à 00:02, gbWilly a écrit :
>
>> I have been working at that, but in new master I do not know where to
>> put my changes.
>
> The template files for Debian are located in the 'template/debian'
> directory. Those are the files that must be updated.

I get it but your debian12 recipe folder has 20 files, mine has 133!!
You control file has code in there to insert stuff. Impossible to compare.

I can only compare end result being the debian.tar.gz in .osb., but can't merge my changes to the recipe like before.

> You have to compare the generated debian files in the '.obs' directory
> with your own files, and tell me the differences, i.e. what should be fixed.

It would be easier if the generated recipe would also be in kept in the build dir (the full created recipe I mean) that makes up the debian.tar.gz.
That builded recipe before making tars , made by gambas-package-config, I can easy compare and update with my changes, by simply copying my changed files over your recipe and do merge request.
Then on gitlab you can see the differences very clearly in the merge request. So why not keep build folder as copy these purposes?

Is that not easier than now having to:
1. unpack debian.tar.gz in .obs
2. compare all files line by line for endless details again, write all down, so I can report where I changed things exactly as merging them is impossible?

Next I have to somehow explain all the differences like
Line 235 of control I removed a dependency on...
Line 425 of control I corrected spelling mistake
Line 465 ..

All work done to get to this recipe took many days and was tested many times over in real builds to perfect it.
What you ask is almost doing all over again, just to be able to report the changes to you

As I said, unpack debian.tar.gz in a folder, so I can merge my change in there. I will simply pull it in, copy past my recipe over your unpacked folder and do a merge request. No line for line comparing and explaining needed from my side, saves me many hours of work, and git can show you the changes in merge request better than I can remember them.

Next about the .dsc file:
The .dsc file is based on another recipe and pointing to debian as upstream instead of gambas gitlab as upstream.

The .dsc should be generated from source + your recipe and next modified slightly (native to quilt, version needs -1 added, checksums can go and specific osb references to debian.tar.gz etc needs to be added)

To see what needs to be different it is again easier that I make a complete new .dsc file based on my current most recent recipe, place that in .osb and do a merge request. But, is it okay merging into .osb folder as it looks like a final result folder?
Again online on gitlab you can then very clearly see the all differences between your version .dsc and the merge request .dsc even before accepting and thus know where to adapt your code for making all work.
Those difference files in merge requests tell you more that I can even explain. And those comment fields in merges can give detailed added info and questions can be asked and answered, to clarify the subject.

To make the .dsc I would extract the source code in a build location, create debian folder in there and next run dpkg-source -b <path/to/unpacked/source. dpkg-source -b build .dsc and source with recipe included in seconds. Write some code to do mentioned changes to the created .dsc (native to quilt, version etc) and you have a new .dsc every time and streamlined with ALL CHANGES in the recipe that might have occurred

A few things .install files can be in recipe without being used, but make sure they are not mentioned in control file and if needed disabled in rules file, then the build will ignore them
For example, qt,install files in 3.19.90 recipe for debian12 can stay in there for debain11.

> Then I will know what should be updated in the template, and eventually
>
> if more subsitutions commands should be added.

I get your point, but these substitutions make comparing a hell and merging impossible. You somewhere need to be able to compare your result, with changes made and be able to merge these, outside your template.

> Regards,
>
> --
>
> Benoît Minisini.

Off to sleep, way to late,

gbWilly

>