This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1013439 - procps build problems
procps build problems
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: procps-ng (Show other bugs)
19
Unspecified Linux
unspecified Severity medium
: ---
: ---
Assigned To: Jaromír Cápík
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-30 01:11 EDT by George R. Goffe
Modified: 2016-01-31 20:59 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-17 12:24:51 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description George R. Goffe 2013-09-30 01:11:09 EDT
Description of problem:

using ./configure --prefix=/usr/lsd/Linux produces /usr/lsd/Linux/usr/bin during make install


Version-Release number of selected component (if applicable):

procps-ng-3.3.7-3.fc19.src.rpm

How reproducible:

Readily failing with --prefix= specified. Also fails for --prefix=/usr. Make install produces /usr/usr/bin.

Steps to Reproduce:
1../configure --prefix=/usr --verbose
2.make clean depend
3.make
4.make install

Actual results:

see above

Expected results:

make install should send the install files to wherever --prefix= points.


Additional info:

This failure occurred on my Fedora 16 system (I know, it's not supported). My Fedora 19 system is not available right now due to hardware problems at my end. I would almost bet money that it will fail on Fedora 19 (I'm a conservative better). :-)
Comment 1 Jaromír Cápík 2013-10-02 10:02:26 EDT
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.
Comment 2 George R. Goffe 2013-10-19 06:08:25 EDT
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...
Comment 3 Jaromír Cápík 2013-10-21 11:40:07 EDT
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.
Comment 4 George R. Goffe 2013-10-21 15:07:41 EDT
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...
Comment 5 George R. Goffe 2013-10-21 15:30:22 EDT
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
Comment 6 Jaromír Cápík 2013-10-23 10:12:43 EDT
(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.
Comment 7 Jaromír Cápík 2013-10-23 10:28:40 EDT
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.
Comment 8 Pavel Raiskup 2013-10-24 03:05:20 EDT
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@gnu.org' 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
Comment 9 Pavel Raiskup 2013-10-24 03:23:23 EDT
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.
Comment 10 George R. Goffe 2013-10-24 03:56:04 EDT
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...
Comment 11 Pavel Raiskup 2013-10-24 05:03:29 EDT
> 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
Comment 12 Fedora End Of Life 2015-01-09 15:02:07 EST
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.
Comment 13 Fedora End Of Life 2015-02-17 12:24:51 EST
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.

Note You need to log in before you can comment on or make changes to this bug.