procps-ng is a mistake (was: Re: Summary/Minutes from today's FESCo Meeting (2012-05-14))

Miloslav Trmač mitr at
Mon May 14 20:33:22 UTC 2012

On Mon, May 14, 2012 at 10:10 PM, Lennart Poettering
<mzerqung at> wrote:
> On Mon, 14.05.12 14:45, Stephen Gallagher (sgallagh at wrote:
>> * #851 F18 Feature: procps-ng (next generation procps tools) -
>>  (sgallagh,
>>   18:11:34)
>>   * AGREED: Feature procps-ng is accepted (9 +1)  (sgallagh, 18:14:47)
> Karel Zak has made clear that he is happy to merge procps into
> util-linux (Karel is both upstream and downstream for u-l), and has offered
> to do the work.

Yet he told me that he is happy with procps-ng, and the revival was
very much needed.  Karel?

> util-linux is the much better place for these utilities,
> so that common code, the development infrastructure, the build system,
> the documentation scheme, the release cycle and the maintainership can
> be shared.

Why is the pairing of procps and util-linux any more special than
pairing, say, coreutils and bzip2?  "Common code, development
infrastructure, documentation scheme, release cycle and
maintainership" can always be shared.

IMHO common code belongs in a generally useful library for the
platform (e.g. glibc, glib2), not in some package-private git
repository in each project, where the code slowly rots.

And if /proc accesses are that generally useful to be put into a
library, that library surely should have a stable API, belong in the
procps project, and be used by other projects (including
util-linux-ng) as necessary.

> There's really no point in all the bureaucracy for such a transition
> if it just replaces one bad situation with another bad situation. If you
> do a transition then do it right and merge procps into util-linux.

What bureaucracy?  And if you look closely enough, the transition _has
already happened_, there is an actively maintained cross-distribution
shared git repo.  The old and new situations are not at all same.

> I'd really like to see FESCO strongly ask the people behind procps-ng to
> help working in the integration of its tools into util-linux, to make
> the basic set of tools more nicely integrated rather than continue to
> grow apart!

What does "nicely integrated" mean, really? The tools have their
documented behaviors.  Putting them into one git repo won't make them
magically more integrated - and it won't even make them magically more
maintaned; actually, two separate projects means more proud
maintainers, so it is pretty likely to mean more manpower overall.

> There's really no point in just rubberstamping everything
> people suggest. FESCO should push people in the right direction, and
> push them towards collaboration. FESCO, please steer fedora (and Linux)
> in the right direction here, that's your job!
Ignoring the obvious difficulties[1], how can FESCo push upstreams to
start or not to start work on a particular project, and how can it do
so before the project is done enough to be proposed for integration?

We had an unmaintained procps upstream and 50 Fedora-specific patches.
 Now we have a distribution-common upstream with active development.
Seems pretty close to the right direction to me.[2]

[1] Opinions differ on the Right Direction.  I wonder how pushing
systemd to be less "nicely integrated" would be received, for example
:)  Or the eternal "non-technical user simplicity" vs. "syadmin
flexibility" debate.
[2] Even introducing some F17->F18 incompatibilities to be the same
across distributions.  Great, right?

More information about the devel mailing list