Re: A side note on depricated components vs packagage possibilties (debian)

[gbWilly <gbWilly@xxxxxxxxxxxxxx>]

On Wednesday, December 4th, 2024 at 23:47, Benoît Minisini <benoit.minisini@xxxxxxxxxxxxxxxx> wrote:

> Le 03/12/2024 à 22:25, gbWilly a écrit :
> 

> Even if, for example, 'gb.db2' has the same API (at the moment) as
> 'gb.db', the replacement of 'gb.db' by 'gb.db2' in a program is entirely
> up to the program's author.
> 
> Automatic replacement is too dangerous, because it can break a program
> outside of the author's responsability if there is a compatibility bug
> in the new component.

Maybe gb.db is a bad example as db2 has barely seen the light.
It was just an easy example to show how it can be done in a debian recipe, that's all.

But there are components that can't be packaged on more recent distro's and that are also deprecated.
If code compatible would that not be a solution to make older packaged projects, still install and work, instead of not install at all.
So, I'm talking components that are deprecated + no longer able to be packaged on a distro where old applications (if code compatible) still could install and work.
But then again, this can go on forever...

> If the author want to switch to the new component, it will have to make
> a new version and a new package of its program.

That is a valid point too and is what I do myself.
But diving into the possibilities of packaging makes me think about possibilities that might be useful and then start these kind of debates.
It is always good to evaluate pro's and con's and hear other opinions.

> So no automatic replacement, thanks!

I wouldn't dare without agreement of the boss ;-)

gbWilly