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

[gbWilly <gbWilly@xxxxxxxxxxxxxx>]

On Wednesday, November 27th, 2024 at 21:37, munix9 <munix9@xxxxxxxxxxxxxx> wrote:

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

Oh, I have seen them, but never in the official gambas3 packages is what I meant.
And I have made them once, next to figure out how to prevent them from being made again.
As I say, they pollute my view on listing of gambas3 packages present on my system as I have no interest in dbgsym and neither does the average Gambas3 user, who wants to use it to make applications.
I package for people who want to use Gambas3, simple as that, and that should be our aim.

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

These rules insure stability a certain in the debian eco sytem. They make stuff work as it should.


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

the +39.1 is allowed, but why add it?


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

Doesn't the obs build system use the version in first line of control file in debian folder provided as debian.tar.gz, why else would it need it?
If so, you can use anything you like, as long as is according to debian rules, as debian build tools will simply not build with versions not allowed.
Or did OSB decide to make it's own version number? I have no idea how osb builds, I only know the debian build method.

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

Why, you have recipes for different distro's, do not the recipes include the versioning in other than debian binary builds?

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

I absolutely agree with this...
OBS seems more like a workaround to each distro having it's own proper hosted gambas3 repository.

The most ideal situation would be a gambas3 community webserver hosting gambas repositories (and wiki, mailing list etc) for the different distro's an automate that.
So, any rich guys out there wanna donate a decent webserver renting for a loooooooooong time as a donate, could set us up for something like that + some volunteers to do stuff?

I've been working for a while, doing stuff manually and documenting each step in detail. This for making a setup to automate packaging and creating a signed repository with the build binaries
Matter of having:
1. proper template recipe (too much factors to take into account to automate this, so hand made is best here IMHO)
2. series of base vm's (different archs and debian versions in my case)
3. host machine of the vm's triggers a build by first making different version recipes from template (automated) and next do an auto-clone of all different vm's and start them 1 by 1.
4. vm's are already pre-automated to, at startup, get the source, the proper recipe, proper dependencies file and do a build complete build and next return binaries to host machine.
5. host machine is automated to use all returned builds and create a proper signed debian repository

The only missing link is a webserver to publish said debian repository.
I do plan on building above as all tools needed to do so are there in the debian ecosystem. Debian does it with their all their own tools (combined with a git site) and so can we I think.

It would even work for Ubuntu me thinks (is downstream of debian after all, so why not)

gbWilly