Re: Initial version of 'gambas-package-config' tool

[munix9 <munix9@xxxxxxxxxxxxxx>]

Am 27.11.24 um 19:40 schrieb gbWilly:
> On Wednesday, November 27th, 2024 at 18:59, munix9 munix9@xxxxxxxxxxxxxx 
> <mailto:munix9@xxxxxxxxxxxxxx> wrote:
>
>     Am 27.11.24 um 17:57 schrieb gbWilly:
>
>         Does osb build service provide an option to prevent the debug symbol
>         packages to be made?
>
>     Debug packages are actually a good thing to make it easier to fix
>     errors.
>     But this can be deactivated, even individually for each distribution.
>
>
> Ok, nice.
> They pollute my synaptic package manger, official debian never has them, 
> neither do I.

https://wiki.debian.org/DebugPackage

Just because you haven't seen something doesn't mean it doesn't exist ;-)

>     Benoît should think about whether and where this makes sense.
>
>         And why the addition +39.1 to the version, is that an osb build
>         thingy too?
>
>     This is a test on my part:
>
>     DEBTRANSFORM-RELEASE: 1
>
>     It is also about how the naming of the packages (version - release)
>     should/could look like.
>     Also something Benoît can think about ;-)
>
>
> Well, debian versioning is bound to rules (https://www.debian.org/doc/ 
> debian-policy/ch-binary.html#the-version-of-a-package <https:// 
> www.debian.org/doc/debian-policy/ch-binary.html#the-version-of-a-package>).
>
> For example, you build quilt so:
> - 3.19.6 is NOT allowed
> - 3.19.6-1 IS allowed.
>
> The - is required in a quilt build, forbidden in a native build (it will 
> not build)!!
>
> Quilt builds can be redone, so 3.19.6-1 if they turn out to have some 
> error and thus needs to be repackaged as 3.19.6-2 to be a higher version 
> as 3.19.6-1 to be able to update to the newer package of same gambas 
> version.
>
>
> For stable a simple version like:
> 3.19.6-1 should do just fine

Rules are there to be broken... otherwise the human world wouldn't look 
the way it does - but that's another topic.

I do think that "+39.1" is allowed, because firstly I read some 
possibilities in "2.5.8. Debian package file names" and secondly the OBS 
people would never have built in something that would upset the Debian 
troops - you know how sensitive they can be sometimes ;-)

https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_debian_package_file_names

> So for master I would propose something like:
> 3.19.90-<yyyymmddhhnnss>+<short commit number>
> The <yyyymmddhhnnss> part will ensure each next build is a higher 
> version and updates previous daily build.

Hm, that's not possible (unless you hack the OBS, which is open source).
What works is something along the lines of 3.19.90-<yyyymmdd>+<short 
commit number>

https://github.com/openSUSE/obs-service-tar_scm/blob/master/tar_scm.service.in#L67

And please do not forget: The setup must satisfy all distributions 
offered, compromises are necessary.

Otherwise you can set up a separate project and a separate setup in OBS 
for each distribution, if necessary patch the OBS so that it meets your 
own requirements - this is no longer maintainable.

And finally, the best solution is to publish Gambas on the respective 
build system of the distributions (Arch, Fedora, Debian, Ubuntu, 
openSUSE, ...) - in my opinion, this is rather undesirable.


>     thx,
>     regards
>
>
> Your welcome,
>
> gbWilly


Regards