Re: A possibly clever idea...

[Tim Dickson <dickson.tim@xxxxxxxxxxxxxx>]

Just a note to echo Jussi's sentiments. It's nice to have a like-minded 
view :-)
As a package maintainer for a number of packages for the distro I use, 
the number of times devs jump to the "latest" deps, and dev tools, 
making them minimum requirements can be annoying.
especially when everything still works just fine with older versions. It 
almost reminds me of corporate (think Microsoft) development, where new 
stuff is added deliberately to make previous stuff
not work. Open Source is not immune. the mess with gnome soup3 vs soup2 
where a new lib does not have the global support required, but software 
has to pick one version or another, or x11 and wayland to mention 
another similar platform mess. Having extra features but maintaining 
backward compatibility is a goal worth aiming for. The current trend of 
running every little bit of software in it's own vm/sandbox just makes 
for bloat and slow software. Not to say don't give it a go if it floats 
your boat. I do package testing on a vm, and if i was being good, I 
would use filesystem snapshots so I could roll back after each build. 
instead I use an overlayfs, just to make sure stuff is written in sane 
places, and don't bother using snapshots because i'm lazy and don't want 
to have to rebuild all the deps each time :-)

Regards, Tim

On 10/10/2024 02:09, Jussi Lahtinen wrote:
> I absolutely hate docker, flatpak, snap, appimage, etc.
> First people write unportable code, then instead of fixing the root 
> issue, they make an absolutely huge bloated trash package that 
> "overcomes" the portability issue and call it a solution. Just imagine 
> the mess if everyone would choose to use those.
> Instead (not in any particular order):
> 1. Work towards updating the repos.
> 2. Avoid newest, experimental, etc features if possible.
> 3. Write code that is not system specific, but adheres to broader 
> standards like POSIX.
> 4. Keep backward compatibility in mind when maintaining the software.
>
> I'm sure I forgot something, but you got the point.
>
>
> Jussi
>
> On Thu, Oct 10, 2024 at 2:40 AM Bruce Steers <bsteers4@xxxxxxxxx> wrote:
>
>     I've just recently discovered docker and all it's possibilities.
>
>     I have a theory that may get around the Gambas upgrading to latest
>     version.
>
>     My theory is that on my online droplet I could set up docker
>     images to have all the supported ci systems set up with a Gambas
>     source directory that has mostly all the commands (reconf,
>     configure and make) done but not make install.
>
>     Then all I require on my local system is to download the almost
>     built source code and get the dependencies needed to run make install.
>
>     But what exactly is also likely to be needed?
>     I assume a lot of the dev files could be omitted but their
>     binaries packages still needed.
>     This issue assumes Gambas is already installed via package
>     manager. If you already have autotools install then you'll likely
>     have all dependencies anyway, and know what you're doing.
>
>     Maybe a better question is not what's needed but what could I
>     exclude to just make install a mostly made source?
>
>     What you think?
>     A crazy unworkable idea?
>
>     Or could I be onto something?
>
>     I'm gonna test the theory on my systems that have all dependencies
>     anyway.
>
>     Respects
>     BruceS


--
This email has been checked for viruses by AVG antivirus software.
www.avg.com