Re: newlib wrapup

On 12/4/20 1:22 AM, Craig Small wrote:
> You mean move the procps_ns* into procps_misc? OK though most of 
> those are just .so links to the main page.

Hi Craig,

I wasn't inclusive enough. Here's how things might be organized.

As a minimum, the procps_misc man document should probably include all 
the miscellaneous stuff such as procps_linux_version, procps_ns*, 
procps_uptime*.  It could be organized via #include file (no longer 
installed to proc/ but rather procps/).

And if the sysinfo sources also consolidated what is currently in the 
namespace, uptime and version sources, that would simplify the above man 
page.  I would then rename 'sysinfo' sources as 'misc' and cleanup all 
the dependencies.

So in summary, beyond the 6 major APIs (6 headers documented in 2 man 
pages) we'd end up with 1 additional header and man document.

> 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

I agree no major API changes.

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

That sounds good to me.

As for naming I leave it up to the true maintainer.  But if we abandoned 
libprocps we would likely need to change the header install directory, 
source name prefixes and man page names/content.

> 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.

Remember, we've already had one early adopter:

https://www.freelists.org/post/procps/limited-usability-of-the-library-libprocps-from-an-external-software,2

Regards,
Jim