> * #851 F18 Feature: procps-ng (next generation procps tools) -
> * AGREED: Feature procps-ng is accepted (9 +1) (sgallagh,
Ahem. I think is is a really bad idea. "-ng" packages point to a huge
failure in the handling of the packages in question, and should not
be deemed a feature for Linux but a failure of Linux.
Says who? You? It must be true then!
It seems you really know, how to manipulate people, because the first
thing I told to myself after reading this part of your message
was : "What a melodic statement!"
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
to do the work. util-linux is the much better place for these
so that common code, the development infrastructure, the build
the documentation scheme, the release cycle and the maintainership
Why don't we create just one big package called for example
"fedora-distribution" ? We could merge everything inside, because
there must be a lot of common functions in all Fedora packages.
Let's start doing it immediately, because it could take quite
a long time!
How much do you know about the procps and util-linux internals?
Is it the knowledge or self-importance what makes you claim that?
There's really no point in all the bureaucracy for such a
if it just replaces one bad situation with another bad situation.
There is. We had to change the name, since the former upstream
is still somehow alive, but not enough to make us happy. And as
there can't be two independent upstreams called procps, we decided
to change the name to avoid conflicts. I strictly disagree with
your opinion here. I don't consider procps-ng a replacement with
another bad situation.
I'm curious where you get enough courage to disparage effort and work
of other people. That's the same like claiming that systemd is
replacement of bad situation with even worse situation.
How do you like it?
If you do a transition then do it right and merge procps into
Please, stop being always right, especially when you don't know much
about projects you're trying to break.
We really don't need two packages with such overlapping
Is it overlapping? I believe it isn't. The tools would need to be
completely redesigned and rewritten to possibly have at least
a small set of common functions with util-linux. The question is
if it is worthy enough for such a change.
The current procps state is so bad, that we had to act really quickly
and the unification in form of procps-ng was really inevitable.
Both of them had long phases in their history where
were slowly rotting along. The best way to fight that is having a
package from it so that this easier kept an eye on.
Again. Why would it be easier? Because you said that?
They do very similar stuff
Do they? You mean that tiny part touching the proc filesystem?
Sorry, but I don't consider tools like fdisk or fdformat similar
to tools like top or vmstat. Each of the tools has it's purpose
and if anything inside is overlapping, then it's just a very small
part and that could eventually be moved to a common library one day.
But I believe there's more important work to be done here than
playing with reordering the particular tools, moving them from
package to package and creating just one huge monolithic rpm, that
breaks the basic principles of modularity.
,they need the same expertise from the hackers and maintainers
they should justbe one.
Really, nobody needs transitions, renames and multiple independent
for stuff that is very very similar in purpose and behaviour.
Nobody? That means we're nobody for you, right?
I remember such superior attitude from somewhere.
Yes. It was one of my previous jobs where everybody was leaving
the team because of one manager with similar attitude.
I'd really like to see FESCO strongly ask the people behind procps-ng
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! 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
in the right direction here, that's your job!
I'm happy that FESCO members are rational enough and are able to have
their own point of view and opinions.
Lennart Poettering - Red Hat, Inc.
devel mailing list