[procps] Re: procps changes
- From: Sami Kerola <kerolasa@xxxxxx>
- To: procps@xxxxxxxxxxxxx
- Date: Fri, 23 Sep 2011 07:00:30 +0200
On Fri, Sep 23, 2011 at 01:28, Craig Small <csmall-procps@xxxxxxxxxx> wrote:
> On Thu, Sep 22, 2011 at 04:10:05AM -0500, Jim Warner wrote:
>> Lastly, do you think that libproc-3.3.0 should also carry the "ng"
>> identifier? Albert's version may shortly be at the same level and that
>> would avoid a name collision.
> I think it should be libproc-ng so there is no mistake on what it is.
> Debian has a few build dependencies on libproc-dev which means they link
> to libproc but it is not many.
Change is pushed to my git.
https://gitorious.org/~kerolasa/procps/sami-procps-ng/commit/208519b2f6de8a8fcb2992c3ca3f5a9618cb4e4c
> autotools is a pain but it solves a lot of problems too so I do think
> putting it in will help with things. The wierd install directories is a
> standard part of how it works.
I think you are referring to change bellow. Again I tried to keep in
paths where they where before autotools where reintroduced. One could
say that rather than redefining usrbin to be /bin the programs should
be listed as bin_PROGRAMS in Makefile.am. I am ready to say there
this patch should not be accepted, reason being that some users expect
paths not to change and I do not find any good side in doing such.
https://gitorious.org/~kerolasa/procps/sami-procps-ng/commit/cf4edbe4a27779d6a678ded3fe5b54f63cf35685
Comments?
> Don't fiddle with rpath on anything you put into git, I still remember
> the bad old rpath mess days.
Now you lost me.
> We probably should be aiming for a release soon. I think the auto* plus
> the procps ng changes is a good place to draw a line in the sand and get
> a new version out. I know Debian is not near a new stable release so it
> works for me.
>
> I've been toying with the idea of internationalising procps too. Not
> before the release but afterwards. Most of the main tools have this
> feature and I've converted programs before that do this and its
> reasonably straightforward. Albert was against it because he didnt want
> to add dependencies but its there in ls etc so the hit is already been
> taken.
Sounds good to me. As all strings need to be touched it may be good
idea to have Documentation/ with files telling how not to make mess of
usage functions. Similar thing was recently done with util-linux.
https://github.com/karelzak/util-linux/tree/master/Documentation
Assuming documentation directory will appear it would be nice to get
project read me files cleaned up. I can see the BUGS and CodingStyle
could be better. It would be also quite nice to get some sort of
release information to docs dir telling how often releases happen, how
version numbers change etc stuff that hopefully makes people managing
packages slightly happier. That would also advice contributors not to
send big experimental change just before shipping, or at least would
make it more understandable why the patch was halted for some time.
> I'll work on getting the patches into git this weekend if they're not
> already there and do some testing.
Here they are the way I think they should be split.
https://git.gitorious.org/~kerolasa/procps/sami-procps-ng.git ng
BTW I see that quite big changes are favored, such as
git show c2dcbef4826806f85b7ad6de2d9fe99bc390d603
Am I heretic if I propose that perhaps smaller changes would be
better? My rationality is that letting cherry picking and being able
to nudge out just the problematic part (such as usrbin change) is
valuable. And not matter if big or small changes are favored perhaps
telling about it in docs dir is they way to go.
--
Sami Kerola
http://www.iki.fi/kerolasa/
Other related posts:
