[Buildroot] [PATCH 2/2] package/lzlib: remove it

Yann E. MORIN yann.morin.1998 at free.fr
Tue Jun 15 19:48:27 UTC 2021


François, All,

On 2021-06-15 13:30 +0200, François Perrad spake thusly:
> Le lun. 14 juin 2021 à 22:27, Yann E. MORIN < [1]yann.morin.1998 at free.fr> a écrit :
>   On 2021-06-13 17:42 +0200, Francois Perrad spake thusly:
>   > Signed-off-by: Francois Perrad < [2]francois.perrad at gadz.org>
>   Removing a package should dully explained in the commit log.
>   lua-zlib that you taunt as a replcement, adertises that it is not 100%
>   percent compatible:
[--SNIP--]
>       To use this shim add the -DLZLIB_COMPAT compiler flag.
> 
> This is done by the rockspec:
> see [4]https://github.com/brimworks/lua-zlib/blob/master/rockspecs/lua-zlib-1.2-0.rockspec#L33

So, this is the kind of information that should be part of the commit
log, for example (e.g.: the rockspec file for lua-zlib automatically
enables this legacy shim, so packages autoamtically inherit it).

However, this is still not a drop-in replacement, because parts of the
API return different types than lzlib did.

So, if some packages really need that part, they can't use lua-zlib.

Additionally, it is still OK to keep an old package in the tree, at
least as long as there is no drop-in-replacement, or that there are
still in-tree users, and as long as it does not cause any build
failure, that is not much an issue...

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'



More information about the buildroot mailing list