[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


On Thursday, November 28th, 2024 at 07:30, munix9 <munix9@xxxxxxxxxxxxxx> wrote:

> Am 27.11.24 um 22:29 schrieb gbWilly:
> 
> > On Wednesday, November 27th, 2024 at 21:37, munix9 munix9@xxxxxxxxxxxxxx wrote:
> > 
> > > Am 27.11.24 um 19:40 schrieb gbWilly:
> > 
> > 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.
> 
> 
> Strange point of view, but to each his own.
> I'd be happy for any automation that would help me fix bugs, even if
> it's just to provide me with debug packages.

It creates a lot of extra packages, you wanted less packages and I don't need those dbgsym packages
That's all...

> > the +39.1 is allowed, but why add it?
> 
> 
> Then it shouldn't be a problem.
> I recommend that you read up on the subject of "consideration of running
> build numbers" in automated systems and perhaps also take a closer look
> at OBS - it can't hurt.

I've got more than enough reading to do on building for Debian.
And I do read on version numbering in automated systems in the Debian ecosystem.
I don't care about how Arch, Fedora and the likes do their numbering and packaging, as I do simply do not use them, nor do I package for them.

> If you (or Benoît) don't want to use it (in Debian/Ubuntu) for whatever
> reason, then I don't care.
> As I said above: take a closer look at OBS - it really can't hurt.

Nobody talked about not using it. I made a test to run, didn't I? And now my main goal is getting some better understanding from someone who knows the OSB system (being you) without me having to study the whole goddamned thing. I have plenty on my plate just within the debian world to study. I spend my whole day today doing lintian checks against my builds and see how to improve the recipe and get some of those lintian warning eliminated, meaning a lot of research online on a documented, but never really explained matter. I have even downloaded other packages to study their recipes on certain matters, for my understanding of the matter. I'm about to package it and see what improvements (or non improvements) I made.

I do of course think of an ideal solution in an ideal world as having a webserver that is gambas3 owned and automate that for building and publishing, so all is within gambas3 control without distro's messing it up. But hey, we do not live in an ideal world... And a man can dream, I hope...

> And one thing should be clear to you: OBS builds the packages in the
> respective environment of the distribution! For Debian 12 a Debian 12 VM
> and Debian 12 build tools are used, for Arch the respective current Arch
> version etc...
> 
> So if a package could not be built at this point because it violates
> some ominous rule, then the build would also fail accordingly.

I am very aware of that, even mentioned that I presumed debian tools where used in a previous post. 
I know that debian uses the debian folder for making all packages (the recipe) and the first line of changelog in there contains the version number for the package and the debian distro it is packaged for. That is why you need a different debian.tar.gz for debian 11 and debian 12. They are the recipe for the debian build toolls to use.

But OSB seems to add to changelog on build and change the version number. I have seen it in the changelog of the test build you did on OSB, so that is why I know and why I ask. Can this be done different so we can control the numbering system for the different distro's?

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

I mean OSB builds packages with tools of the specific distro in the specific VM's, so versions don't have to be exactly the same, as long as first part (like 3.19.6) is there, rest is a bit based on how different distro's think their versions should look like. Would it conflict, or does OSB not like some diversity in the version number?

> > > 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.
> 
> This will be my last mail on this topic, because I somehow have the
> impression that you have built up a certain cool distance, maybe even
> aversion to OBS - for whatever reason.

You yourself said that ideally all distro's should publish gambas on their own build system and that 'this is rather undesirable' referring to the OSB solution I suppose?

And how does asking questions for better understanding means I have an aversion to OSB (or Benoit for that matter)? I'm just being critical, but I'm critical to literately everything in life even myself, not just about OSB and with a reason, I prefer quality over quantity and quality needs a critical approach to get a good understanding of the matter, before doing anything

Simplifying things is not always a good thing. Complexity usually has a reason, the reason being stability and quality. Simplification also often has a reason, lack of skill and understanding of the matter, no time for deepening the matter or trying to provide bulk in a short time, often at less quality.

That is what I see happening all my life, products used to be of good quality (when I was young), repairable and there where skilled people who could repair them, now all has become trow away and simplified by electronics that will never last as long as their, once mechanical, counterpart (like in cars for example). But hey, they can sell you the products more often now. Just wait until all people with electric cars will have a dead battery, some years from now. Replacing that battery for an electrical might be more expensive than a new car...

Kids can use a calculator at school (not when I was young) but can't even do some simple math without it. Imagine a world without electricity for a month? Most people would be lost, not able to do anything as they lack the skills of doing things without all the easy and simplified tools to help them do it. They will lack complete understanding of underlying processes and the skills and experience to do them, they would be back like little kids at kindergarten, not being able to do stuff I grew up with. Progress they call it... 

And being witness of this 'decrease in quality' in everything all my life, has made me very critical to all that is thrown at me. So, I ask questions, try to figure out.

I am someone who has no smart phone, I can only go online if I start up my computer and I am about to dump my old 2G mobile phone for an old fashion home connection. I drive an old car, have no electrical kitchen appliances except a fridge etc and I prefer to do stuff myself with my 2 hands and brain and thus improve by capabilities and insight on many many things.

Less easy, you say? Only for the unskilled, I say. And never trying to do shit and relying on all being simplified will keep you at that unskilled stage...

It costs more time and effort, you say? Check how many hours you spend on you smart phone and tell me again, still no time, to become more skilled, to do real stuff and experience the joy of being able to do stuff?...

No money in the world that can replace what you can and none can take that from you (unless you get demented of course ;-).

> Maybe because your own project to provide debian packages for Gambas is
> supposedly being pushed into the background, I don't know

My project is only costing me a lot of spare time, not even knowing if anyone uses it as I haven't had any feedback so far.
But that is not why I do it, there is 2 big reasons:
1. Just trying to provide a more recent gambas3 to debian stable version, that also meets the specs Benoit would like to see.
2. See if I can figure it all out and improve my insight and skills within the debian ecosystem

I have my know how and skills improved and thus it has been very insightful and useful so far.
And more time for me if it comes obsolete, I still have many many other thing I want to figure out and improve my insight and skills, so hey, no loss there...

> 
> Read up on the possibilities of OBS or don't.
> Create an account there and test it or leave it.

And I don't understand why so hostile, I have no quarrel with you, why?
And, I don't mind when people get critical about stuff I do, it gives me an opportunity to explain, learn, improve and all that kind of good stuff to make me grow as a person...

And again thank you for the test and the answers that you did provide.

Enjoy a good glass of wine, I will too.
So off to preparing a meal, packaging will have to wait as I spend way too long on this mail.

Cheers,

gbWilly



Follow-Ups:
Re: Initial version of 'gambas-package-config' toolT Lee Davidson <t.lee.davidson@xxxxxxxxx>
References:
Initial version of 'gambas-package-config' toolBenoît Minisini <benoit.minisini@xxxxxxxxxxxxxxxx>
Re: Initial version of 'gambas-package-config' toolgbWilly <gbWilly@xxxxxxxxxxxxxx>
Re: Initial version of 'gambas-package-config' toolmunix9 <munix9@xxxxxxxxxxxxxx>
Re: Initial version of 'gambas-package-config' toolgbWilly <gbWilly@xxxxxxxxxxxxxx>
Re: Initial version of 'gambas-package-config' toolmunix9 <munix9@xxxxxxxxxxxxxx>
Re: Initial version of 'gambas-package-config' toolgbWilly <gbWilly@xxxxxxxxxxxxxx>
Re: Initial version of 'gambas-package-config' toolmunix9 <munix9@xxxxxxxxxxxxxx>
Re: Initial version of 'gambas-package-config' toolgbWilly <gbWilly@xxxxxxxxxxxxxx>
Re: Initial version of 'gambas-package-config' toolmunix9 <munix9@xxxxxxxxxxxxxx>