Bug 443611 - Review location of IPA commands
Review location of IPA commands
Status: CLOSED WONTFIX
Product: freeIPA
Classification: Community
Component: ipa-admintools (Show other bugs)
1.0
All Linux
low Severity low
: v2 release
: ---
Assigned To: Rob Crittenden
Chandrasekar Kannan
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-22 11:15 EDT by David O'Brien
Modified: 2015-01-04 18:31 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-02-16 13:15:56 EST
Type: ---
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 David O'Brien 2008-04-22 11:15:50 EDT
Description of problem:

Transcript of sso mailing list discussion:

>>>>> There are two solutions. If a user is going to be administering IPA they
>>>>> might add /usr/sbin to their path. As a developer I always
>>>>> have /usr/sbin in my path because I frequently perform administration
>>>>> tasks.
>>>>>
>>>>> However that being said, I think one could argue many of the IPA command
>>>>> line tools might not constitute traditional UNIX administration
>>>>> utilities and are more akin to commands belonging to an application,
>>>>> which normally reside in /usr/bin. Thus the second option is to move the
>>>>> commands from /usr/sbin to /usr/bin, perhaps we should consider this.
>>>>
>>>> Yes, we should probably move most of them in /usr/bin
>>>> Luckily on Fedora they will start putting /usr/sbin in the default path
finally, but on RHEL it will matter for some time.
>>>>
>>>> Simo.
>>
>> I put them into /usr/sbin because these are definitely sys admin commands,
even if they don't necessarily happen while the user is 'root' or update the
local system.
>>
>> I'm flexible.
>>
>> This would happen post-beta but would be relatively trivial to fix in the
tree for new installs. Upgrades are slightly more complex.
>
> rpm takes care of that, unless you are thinking of make install kind of
upgrades :)
>

No, I was thinking rpm. We'll need a %pre or %post to remove the old bits
though, right? Or will that happen automagically? It would be nice if it did. 

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


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Martin Nagy 2008-08-14 01:40:14 EDT
So, is the decision to make the move or not made yet? If yes, we should either do this as fast as possible or close the bug.

BTW the removal of old files wouldn't be necessary, rpm takes care of that.

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