new package: libcap - deal with posix capabilities

[abraXxl]

libcap integration

patch against r8609

@abraXxl:

• warum 2.19, es gibt inzwischen 2.22?
• statt $(TARGET_CROSS) verwende bitte TARGET_CC, TARGET_AR, TARGET_RANLIB (die letzte fehlt)
• -I$(TARGET_TOOLCHAIN_STAGING_DIR)/include und -L$(TARGET_TOOLCHAIN_STAGING_DIR)/lib sind wahrscheinlich überflüssig (ungetestet)
• uninstall-Regel enthält libattr statt libcap und verwendet $(PKG)_TARGET_DIR (im Body einer Regel dürfen keine $(PKG*)-Variablen verwendet werden)
• so wie ich es verstehe wird nur die Library gebraucht. Es wäre besser auch nur diese zu bauen, dafür alle $(SUBMAKE) -C $(LIBCAP_DIR) durch $(SUBMAKE) -C $(LIBCAP_DIR)/libcap ersetzen und clear-Regel entsprechend anpassen

Neue Version des Patches:

• Version auf 2.22 angehoben
• TARGET_CROSS durch TARGET_{CC,AR,RANLIB)
• -I$(TARGET_TOOLCHAIN_STAGING_DIR)/include und -L$(TARGET_TOOLCHAIN_STAGING_DIR)/lib entfernt
• uninstall Regel gefixed
• vsftpd angepasst, da er sonst libcap nutzt und dagegen kompilieren möchte.
• Binaries entfernt

@er13: danke, schau bitte noch mal drüber

Sieht vom Lesen her gut aus. Hast Du getestet, ob es irgendwelche Konflikte mit libcapi gibt? Ich kann mir vorstellen, dass wenn man libcapi baut (d.h. diese unter packages/…root… landet), dann diese doch abwählt und libcap (ohne i) mit ins Image aufnimmt, libcapi trotzdem aufgenommen wird (weil libcap* blöderweise auch libcapi matched).

Edit: so wie sich dieser Abschnitt für mich liest, wird es leider einen Konflikt geben…

Ich wollte gerade mal Deine Patches einspielen. Kannst Du die auch so vorbereiten, daß ein normales patch -p 0 < foo.patch im Freetz-Basisverzeichnis geht? Bei wird werden bei beiden Libs Unterverzeichnisse "null" angelegt. Ich weiß natürlich, wie ich das manuell korrigiere, aber das macht es nicht schöner.

Ach so, Tip dazu noch: Mach vorher svn add make/libs/mylib, dann geht ein ganz normaler svn diff, um den Patch zu erzeugen. Nur vorsichtig sein, wenn Du danach eincheckst und die hinzugefügten Sachen nicht rein sollen.

Ohne Null-Pfade

Neue Version des Patches mit einem Update des vsftp-Packages, welches sollte libcap irgendwann mal installiert worden sein (capability.h) libcap verwenden möchte, auch wenn dies nicht selektiert wurde.

Es bleibt IMO noch fwmod anzu passen wie er13 im 4. Kommentar erwähnt hat.

Ich wollte soeben auch einen libcap patch hochladen, als ich dieses Ticket gefunden habe. Ich hätte dazu noch eine Frage als jemand der noch nicht so viele freetz-Pakete gebaut hat: warum nutzt dieses Paket so viele make-Variablen? Ich komme in $($(PKG)_BINARY) und $($(PKG)_STAGING_BINARY) bei mir mit folgendem aus. Ich finde, das sieht übersichtlicher aus.

LIBCAP_MAKE_PARAMS := CC="mipsel-linux-gcc" \
     BUILD_CC="gcc" \
     LIBATTR=no

$($(PKG)_BINARY): $($(PKG)_DIR)/.configured
     $(SUBMAKE) -C $(LIBCAP_DIR) \
          $(LIBCAP_MAKE_PARAMS)

$($(PKG)_STAGING_BINARY): $($(PKG)_BINARY)
     $(SUBMAKE) -C $(LIBCAP_DIR) \
          DESTDIR="$(TARGET_TOOLCHAIN_STAGING_DIR)" \
          RAISE_SETFCAP=no \
          $(LIBCAP_MAKE_PARAMS) \
          install
     $(PKG_FIX_LIBTOOL_LA) \
          $(TARGET_TOOLCHAIN_STAGING_DIR)/usr/lib/libcap.a