Closed
Issue #1 · created by Eric Herman ·


allow directory name changes with unpacked sources

There are a number of cases where the package-users user-name does not match top directory of the source file.

For example, if the package user name is "kernel" but the source unpacks to "linux-4.7.2" then I typically create a symlink so that the build knows what directory to cd into.

I would like to specify a SOURCE_DIR_PREFIX to avoid needing symlink.


2 participants
  • That makes sense. Is it problematic to assume that there's always a hyphen and then a version number?

    Edit in fullscreen
    Markdown tip: Inline code can be denoted by `surrounding it with backticks`
  • The way I have landed on this is different, and I propose it as a simpler alternative. litbuild (and the litbuild package-users variant) now insists that package tar files be named exactly ${PACKAGEUSER}-${VERSION}.tar (optionally lzip-compressed and with an .lz suffix), and must expand into a directory called exactly ${PACKAGEUSER}-${VERSION}.

    This is not the case with a bunch of upstream tarballs -- e.g., the ACL project distributes their source tarballs as acl-${VERSION}.src.tar.gz -- and is certainly not the case for packages like Python, where there may be multiple versions installed and the CBL package user for Python 2 is "python2". So for CBL, I simply unpack the tarball from upstream, rename the top-level directory appropriately, and tar it back up with the correct name. Easy-peasy!

    (You'll note that the cbl-materials.tar file on repo.freesa.org already has everything packed up appropriately for this convention.)

    What do you think?

    Edit in fullscreen
    Markdown tip: Make a horizontal line using three or more hyphens ---, asterisks ***, or underscores ___
  • I think this issue should have been closed with commit c2a0360b .... On the topic of unpacking and re-packing to suit the name, I'm far less inclined in that direction. I'd rather have tarballs which have the same hashes as upstream. (And it feels weird to require the non-automated steps of unpacking and re-packing for something as small as a directory name difference.) Supporting a concept like SOURCE_DIR_PREFIX should be straight forward, shouldn't make the code harder to understand/change in the future, thus it shouldn't have to be a strict either-or decision.

    Edit in fullscreen
    Markdown tip: Denote blockquotes using > at the beginning of a line
  • OK. For CBL and litbuild I am still doing things my way (because I do not care about the hashes from upstream, since I take hashes after I fix the upstream tarball, and downloading is already a non-automated step so why not also fix the tarballs post-download?), so it might make sense to make this change in a variant of package-users that isn't specifically intended to be used with litbuild.

    Edit in fullscreen
    Markdown tip: Blocks of code can be denoted by three backticks ``` or four leading spaces
  • Status changed to closed

    Edit in fullscreen
    Markdown tip: Notify a specific group using @group_name