Bigtop
  1. Bigtop
  2. BIGTOP-463

should we reconsider /usr/lib vs. /usr/libexec decision?

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.4.0
    • Fix Version/s: 0.6.0
    • Component/s: general
    • Labels:
      None

      Description

      I keep running into issue where /usr/lib vs. /usr/libexec becomes a pain. In theory it is doing the right thing, but in practice it complicates maintenance and doesn't seem to give us any major benefits. Given that the only 2 packages that use /usr/lib vs. /usr/libexec are bigtop-utils and bigtop-jsvc, perhaps its not too late to reconsider and keep their content under /usr/lib/bigtop-utils ?

      1. BIGTOP-463.1.patch
        20 kB
        Sean Mackrory

        Activity

        Roman Shaposhnik created issue -
        Hide
        Philip Zeyliger added a comment -

        Bigtop already deviates from distribution defaults in our defaults for chkconfig in certain places; I think that where it's not harmful, it'd be better to be consistent within bigtop rather than across.

        Show
        Philip Zeyliger added a comment - Bigtop already deviates from distribution defaults in our defaults for chkconfig in certain places; I think that where it's not harmful, it'd be better to be consistent within bigtop rather than across.
        Gavin made changes -
        Field Original Value New Value
        Workflow no-reopen-closed, patch-avail [ 12658636 ] patch-available, re-open possible [ 12666081 ]
        Roman Shaposhnik made changes -
        Fix Version/s 0.5.0 [ 12321865 ]
        Fix Version/s 0.4.0 [ 12318889 ]
        Roman Shaposhnik made changes -
        Fix Version/s 0.6.0 [ 12323895 ]
        Fix Version/s 0.5.0 [ 12321865 ]
        Sean Mackrory made changes -
        Assignee Roman Shaposhnik [ rvs ] Sean Mackrory [ mackrorysd ]
        Hide
        Sean Mackrory added a comment -

        I support the idea of using /usr/lib consistently instead of /usr/libexec. I'll start working on a patch - so if you disagree, speaking up sooner rather than later would be appreciated

        Show
        Sean Mackrory added a comment - I support the idea of using /usr/lib consistently instead of /usr/libexec. I'll start working on a patch - so if you disagree, speaking up sooner rather than later would be appreciated
        Hide
        Bruno Mahé added a comment -

        For the sake of documenting the ticket and explaining the need for this ticket, it would be great to detail the issues encountered with /usr/libexec.

        Note that I am not against or for it.

        Show
        Bruno Mahé added a comment - For the sake of documenting the ticket and explaining the need for this ticket, it would be great to detail the issues encountered with /usr/libexec. Note that I am not against or for it.
        Hide
        Sean Mackrory added a comment -

        The only problem I've run into is that invoking bigtop-detect-javahome takes 5 lines instead of 1 - any time you reference it you have to add logic for both locations. As I've seen while adding a bigtop-detect-javalibs scripts for BIGTOP-504, this will just get worse as more functionality is added to bigtop-utils. I don't know if others have run into any problems of a more technical nature - but I just think it will make the wrapper scripts a lot cleaner and quite possibly prevent mistakes in the future.

        The downside to doing this is that packages that depend on bigtop-utils will now need to specify that they need a least bigtop-utils 0.6.

        Show
        Sean Mackrory added a comment - The only problem I've run into is that invoking bigtop-detect-javahome takes 5 lines instead of 1 - any time you reference it you have to add logic for both locations. As I've seen while adding a bigtop-detect-javalibs scripts for BIGTOP-504 , this will just get worse as more functionality is added to bigtop-utils. I don't know if others have run into any problems of a more technical nature - but I just think it will make the wrapper scripts a lot cleaner and quite possibly prevent mistakes in the future. The downside to doing this is that packages that depend on bigtop-utils will now need to specify that they need a least bigtop-utils 0.6.
        Hide
        Sean Mackrory added a comment -

        Just uploading an initial patch. I've spot-tested a few deb and rpm packages and all is well. I still want to do more testing with the hadoop-* packages (as those changes were a bit more extensive), but thought I'd get this up here for any further discussion in the mean time...

        Show
        Sean Mackrory added a comment - Just uploading an initial patch. I've spot-tested a few deb and rpm packages and all is well. I still want to do more testing with the hadoop-* packages (as those changes were a bit more extensive), but thought I'd get this up here for any further discussion in the mean time...
        Sean Mackrory made changes -
        Attachment BIGTOP-463.1.patch [ 12569395 ]
        Hide
        Roman Shaposhnik added a comment -

        +1 and committed

        Show
        Roman Shaposhnik added a comment - +1 and committed
        Roman Shaposhnik made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Roman Shaposhnik made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

          • Assignee:
            Sean Mackrory
            Reporter:
            Roman Shaposhnik
          • Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development