Re: newlib wrapup

Hi Jim,
  You mean move the procps_ns* into procps_misc? OK though most of those
are just .so links to the main page.

I think fixing up the old library and making a new release is worthwhile.
The Debian distribution is freezing soon[1].
Currently, it looks like there was no major API changes to the library
since 3.3.16
csmall@floyd:~/Projects/procps/procps$ git lol v3.3.16..HEAD -- proc/*.h
* b52a2674 (swiggett/procps-patch-1) Fixes small bug in struct proc_t
documentation.
csmall@floyd:~/Projects/procps/procps$ git lol v3.3.16..HEAD -- proc/*.c
* e3196502 misc: eliminate a couple of miscellaneous gcc warnings
* bb1a79f2 library: correct that 'escape_str_utf8' guy's behavior
* 8e0c33be library: adapted to the latest lxc conventions (again)

So we won't be making the dependent packages have to re-build, so to me it
looks like we could get it in before 12th February "soft freeze" although
ideally 12th January might be better so its clear out of the way of all the
Debian freezes.  I don't know how this works with the other distributions.

How about we aim for an old library release first week of 2021 (or earlier
if most of the PR/bugs are done) and after that roll onto newlib?

We also need to re-visit the library name. It can be kept the same (so it
will be v8) or renamed. Gnome used to put a -0 or -1 into the name itself
which can get confusing but it does roll back the version. Alternatively,
it can be named something else and become version 0.0.0 The benefit of that
being its a new package name and if the old library needs its version
increased you don't have a clash.  Technically we're supposed to have all
the old stuff in procps.sym but marked as deprecated if we keep the old
library. We could go real retro and call it libprocfs (2011) or libproc
(pre 2011)!

The first Debian freeze stops transitions (e.g. a new library version means
other packages need to be rebuilt) which means we would need it in very
early January to meet the freeze, which seems to short a time.

My preference is for newlib release early in the new year, but put it into
experimental dist. This means people other than ourselves can try it, but
its a bit of a "warning it might break stuff" to it. Then after Debian
Bullseye releases, put it into main.

 - Craig




1: https://release.debian.org/bullseye/freeze_policy.html



On Fri, 4 Dec 2020 at 07:17, Jim Warner <[email protected]> wrote:

> Hi Craig,
>
> Let's make a deal.
>
> If you roll the 'namespace' stuff into 'sysinfo' (plus the missing
> prologue) and add it to procps_misc.3, then I'll rename the 'sysinfo'
> guys as 'misc' and handle all the dependencies.
>
> With those changes newlib might be good for its initial release.
>
> However, maybe we should first attend to the growing list of issues and
> merges and and do one final oldlib release.
>
> What do you think?
>
> Regards,
>
> Jim
>