Bug 1013439

Hello George.

As the procps-ng binary package touches the whole root filesystem and the prefix definition is pretty vague, it works in a bit different way in case of the procps-ng project. The prefix works like a DESTDIR subdirectory where the installation tree is created. You should stick with --prefix=/ and change the particular sub-destinations (e.g. --bindir, --sbindir, --libdir, --includedir, --mandir, --sysconfdir, --docdir) instead.
If you show me any guidelines, saying, that our approach is incorrect, then we could reconsider the whole thing and do appropriate changes.

Please, let me know. If you have no objections till friday, I'll close this report as NOTABUG.

Thank you.

Regards,
Jaromir.

Jaromir,

I see that none of the discussions I had with your guy made it to this bug. Should I post them here?

As far as I can see, this problem still exists.

Regards,

George...

Hello George.

Of course, you can post it here. As Craig seems to be pretty sure it cannot be easily fixed without changes in the autotools stuff, I won't oppose him unless you find a strong argument to convince me.

At the moment I'm not convinced we're doing anything downright wrong, but I'm still open to that. Maybe you'd like to send a patch? That would be the best way, how to continue.

Please, let me know.

Regards,
Jaromir.

Jaromir,

What do I have to do to convince you guys?

I could give you a list of all the tools I build who behave as I am expecting procps to behave. Would you like that?

George...

Jaromit,

One of the tools I build is the development tree for GCC. This is how they work as well.

George...

     92  ../gcc/configure --prefix=/usr/lsd/$osname --verbose   \
     93                   --with-mpc=/usr/lsd/$osname           \
     94                   --with-mpfr=/usr/lsd/$osname          \
     95                   --with-gmp=/usr/lsd/$osname

(In reply to George R. Goffe from comment #4)
> Jaromir,
> 

Hello George.


> What do I have to do to convince you guys?
> 
> I could give you a list of all the tools I build who behave as I am
> expecting procps to behave. Would you like that?

No. I'd like to see an example of project that by default installs binaries in /bin *AND* /usr/bin or /sbin *AND* /usr/sbin (or their relevant combinations). That's what the issue is about. If the autotools stuff is unable to handle such situation, then there's nothing we can do about that unless the autotools are equipped with a new feature allowing us to do so.
If you're convinced that current autotools are able to handle that situation, then show us how to do that, please ... like I wrote in my previous comment ... a working patch would be the best way, how to convince us.


> George...

Regards,
Jaromir.

CCing Pavel Raiskup, who owns the autotools components. Maybe Pavel could tell us how to deal with that ... or at least tell us who could give us a helping hand.

George, I'm not really sure what are your expectation.  Is that truth that you
want install all binaries from /usr/bin & /bin into /bin?

IIUC, upstream has *very good reason* to install it this way by default.

I don't know about support for --usrbindir in autoconf (and I really doubt
this could be an addition which upstream would incorporate).  Anyway, if you
really think this is worth to implement, ask on 'autoconf' mailing
list.

Solution for you, George:
  - Adjust $PATH, is that really a big problem?
  - or make the directories to be symlinked XXX/bin -> XXX/usr/bin
  - Patch configure.ac (adjust the 'usrbin_execdir' variable for your needs

George, would that be ok?

----

Solution for procps-ng upstream:
  - Allow adjusting of usbin_execdir by AC_ARG_WITH, AC_ARG_VAR,
    AC_ARG_ENABLE, ...
  - make the usrbin_execdir to be set only if it is undefined, this would
    allow George to specify usrbin_execdir in config.site file (for example
    see the F19's /usr/share/config.site file).

  Example using AC_ARG_VAR:
    diff --git a/configure.ac b/configure.ac
    index 057a2c9..aef06d1 100644
    --- a/configure.ac
    +++ b/configure.ac
    @@ -69,7 +69,12 @@ AC_FUNC_MMAP
     AC_FUNC_REALLOC
     AC_FUNC_STRTOD

    -usrbin_execdir='${exec_prefix}/usr/bin'
    +AC_ARG_VAR([USRBIN_EXECDIR],
    +           [specify usrbin_execdir, e.g. '${exec_prefix}/usr/bin'])
    +test "x" = "x$USRBIN_EXECDIR" && \
    +    usrbin_execdir='${exec_prefix}/usr/bin' || \
    +    usrbin_execdir=$USRBIN_EXECDIR
    +
     AC_SUBST([usrbin_execdir])

     AM_GNU_GETTEXT_VERSION([0.14.1])

Pavel

Ahm, I see that there was also mentioned this solution:

  make install usrbin_execdir='${prefix}/bin'

.. in the response to you at
http://www.freelists.org/post/procps/needinfo-requested-Bug-1013439-procps-build-problems,1

But I don't see your reaction so I don't know where the problem is.  Is that
about the default configuration?  I would say that this would be peddling
request for change ... but anyway, the only way would be to convince upstream
to change the default of usrbin_execdir to /usr/bin and for architectures
where separate /bin and /usr/bin are required, it will be still possible to
redefine it.

Pavel,

Thank you for your attention and time you've spent on this.

What I'm building is a tool chain completely separate from the "normal" distribution of a system. I've been doing my builds this way for quite a while with no problems. I specify --prefix=/usr/lsd/Linux (versioned for Linux but can be versioned for Solaris, UNIcos, IRIX, etc). When I say "make install", I get ALL the build products installed starting at /usr/lsd/Linux. When I do this for procps, I get install dirs like this: /usr/lsd/Linux/usr/bin. My users have /usr/lsd/Linux/{bin,lib,lib64,share,...) in their *paths (MANPATH, PATH, LD_LIBRARY) specifications. They typically do not use /bin or /sbin which is where "my" /usr/lsd/Linux design fails. Maybe procps is right after all?

If procps installed like what I've described, the /usr/bin and /bin build products would go to the same directory. This might break the concept of a separate tree for build products for procps but I've seen no problems doing the above since I started building this way (1995). 

Do you understand what I'm getting at?

Regards,

George...

> Thank you for your attention and time you've spent on this.
np

> What I'm building is a tool chain completely separate from the "normal"
> distribution of a system. I've been doing my builds this way for quite a
> while with no problems. I specify --prefix=/usr/lsd/Linux (versioned for
> Linux but can be versioned for Solaris, UNIcos, IRIX, etc). When I say "make
> install", I get ALL the build products installed starting at /usr/lsd/Linux.
> When I do this for procps, I get install dirs like this:
> /usr/lsd/Linux/usr/bin. My users have
> /usr/lsd/Linux/{bin,lib,lib64,share,...) in their *paths (MANPATH, PATH,
> LD_LIBRARY) specifications. They typically do not use /bin or /sbin which is
> where "my" /usr/lsd/Linux design fails.  Maybe procps is right after all?

Thanks for explanation, I think I know what is the problem now.

I don't want to say it is right or bad.  It just works (and it should work
even for you, see next paragraph later).  After I looked on it once again, I
think now that it could be done a little bit better way, though, but I haven't
tried to do it (the /usr part of path should be part of --prefix & the
binaries which are installed outside from this prefix are special cases - and
should be installed directly in / by separate rules (the same way as it is
done now for usrbin), but it is just my opinion).

In any way, both yours and procpc's use-cases are specific; and at least your
situation is not as bad as it looks.  You should not just expect that things
works by having set only the --prefix="" — you should definitely set
usrbin_execdir to '${prefix}/bin' somehow.

> If procps installed like what I've described, the /usr/bin and /bin build
> products would go to the same directory. This might break the concept of a
> separate tree for build products for procps but I've seen no problems doing
> the above since I started building this way (1995).

There are probably architectures for which this is a problem and for that
reason, upstream is against your suggested changes (which is imo acceptable
argument).  IMO: options are there to allow changing the defaults & you should
rather not rely on defaults.

Pavel

This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.