oshazard / apacman

ArchLinux User Repository (AUR) helper and pacman wrapper
https://aur.archlinux.org/packages/apacman/
GNU General Public License v3.0
70 stars 11 forks source link

support optional ABS/customizepkg for repository packages #2

Open ghost opened 9 years ago

ghost commented 9 years ago

(sorry for the feature requests!)

Currently, the customizepkg check (lines 415-419 in /usr/bin/apacman v.0.9) is only applied to packages being installed from the AUR.

However, it would be handy if: -if a customizepkg.d script exists for packages in e.g. core repository or what have you, use ABS to grab package "skeleton" (PKGBUILD, etc.), customizepkg --modify, then build -otherwise install as normally from the packaged version in the repo

A key use for this would be for kernels- I use customizepkg (well, technically customizepkg-scripting, but same invocation) to change some things in the kernel .config. However, I'd imagine this wouldn't be the only useful package one can apply this to and saves a lot of time/manual steps.

If you prefer I could submit a pull request implementing this.

oshazard commented 9 years ago

Unlike the upstream maintainer (packer), I'd certainly accept a pull request.

I'm currently debating if calling the external script would be sufficient or if rewriting what appears to be trivial functionality and embedding a compatible version into apacman would be better.

oshazard commented 9 years ago

@bts368 Okay, so since this feature requires adding functionality to build the ABS packages on demand (which requires duplicating a lot of the existing codebase) this is not a quick patch.

I see you forked it, did you make any headway? I have about half of it written but it's a mess so I'm going to work on other things.

A possible shortcut might be something along these lines:

$ makepkg -s --skippgpcheck --nobuild -e
ghost commented 9 years ago

a flag would definitely be better than nothing!

i took a look but haven't made any commits yet. i'm on mobile atm and can't check- do you have a new features branch or the like so i can see what you have so far? otherwise i should be able to start work on this tomorrow.

ghost commented 9 years ago

i'm looking into this now and seeing how customizepkg might be implemented. I'd suggest something like the following (definitely untested and needs cleaning up, but should convey the general idea):

between lines 560 and 561, a second if-clause and a little bit of (messy) copying from the aurinstall() function:

 ABSTEST=$(pacman -Q $abs > /dev/null 2>&1 ; echo ${?})
 REPONAME=$(pacman -Si <PKGNAME> | egrep '^Repository[[:space:]]*:' | awk '{print $3}')
 if [[ -f "/etc/customizepkg.d/$1" || "${ABSTEST}" == "0" ]] && deptest customizepkg; then
 echo "Applying customizepkg instructions..."

 dir="${TMPDIR:-/tmp}/pkgbuild-$UID/$1"
 sourcemakepkgconf

# this is where the magic should happen
       ABSROOT=. abs 
       customizepkg --modify

# Prepare the installation directory
  # If there is an old directory and aurversion is not newer, use old directory
  if . "$dir/$1/PKGBUILD" &>/dev/null && ! aurversionisnewer "$1" "$pkgver-$pkgrel"; then 
    cd "$dir/$1"
  else 
    [[ -d "$dir" ]] && rm -rf "$dir"
    mkdir -p "$dir"
    cd "$dir"
    curl -Lfs "$(pkglink $1)" > "$1.tar.gz"
    mkdir "$1" 
    tar xf "$1.tar.gz" -C "$1" --strip-components=1
    cd "$1" 
    if [[ $preview &&  -s "$tmpdir/$1.PKGBUILD" ]]; then 
      cp "$tmpdir/$1.PKGBUILD" PKGBUILD
    fi   
  fi

  # check for missing arch
  if [[ ! " ${arch[@]} " =~ " any " ]]; then 
    if [[ ! " ${arch[@]} " =~ " ${CARCH} " ]]; then 
      echo -e "${COLOR6}warning:$ENDCOLOR $CARCH missing from arch array"
    fi   
  fi

  # Allow user to edit PKGBUILD
  confirm_edit "${COLOR6}Edit $1 PKGBUILD with \$EDITOR? [Y/n]${ENDCOLOR} " PKGBUILD
  if ! [[ -f PKGBUILD ]]; then 
    err "No PKGBUILD found in directory."
  fi

  # Allow user to edit .install
  unset install
  . PKGBUILD
  confirm_edit "${COLOR6}Edit $install with \$EDITOR? [Y/n]${ENDCOLOR} " "$install"

  # Installation (makepkg and pacman)
  rm -f *$PKGEXT
  if [[ $UID -eq 0 ]]; then 
    id aurbuild >/dev/null 2>/dev/null || useradd -r -d /var/empty aurbuild
    chown -R aurbuild:aurbuild .
    su -c "makepkg $MAKEPKGOPTS -f" aurbuild
  else 
    makepkg $MAKEPKGOPTS -f
  fi

  [[ $? -ne 0 ]] && echo "The build failed." && return 1
  pkgtarfiles=""
  for i in "${pkgname[@]}"; do
    pkgtarfiles="$pkgtarfiles $i-*$PKGEXT"
  done 

  # Save packages
  if [ ! -d $savedir ]; then 
    runasroot mkdir -p $savedir
  fi
  runasroot cp $pkgname-*$PKGEXT $savedir/
  echo -e "${COLOR5}  -> ${COLOR1}Saved package:$ENDCOLOR $(ls $pkgname-*$PKGEXT)";

  if  [[ $2 = dependency ]]; then
    runasroot $PACMAN ${PACOPTS[@]} --asdeps -U $pkgtarfiles
  elif [[ $2 = explicit ]]; then
    runasroot $PACMAN ${PACOPTS[@]} -U $pkgtarfiles
  fi
fi
ghost commented 9 years ago

oh, i just noticed you have the absrepo() function... also, i hate github markup. hrm...

well, i'd do it in this order: 1.) determine if $PKG is in pacman.conf repos or AUR 1.)b.) (check for --auronly/--noaur, etc.) 2.)a.) if it's in pacman repos (and --auronly isn't set), check if there's an /etc/customizepkg.d/$PKG 2.)b.) if there is, check if abs is installed. if not, print warning and prompt installation of $PKG from .pkg.tar.xz OR quit (presumably so they can install ABS) 3.) if 2 passes, then set ABSROOT to ${tmpdir} (and, hell, why not- cd into it) 4.) abs $ABSREPO/$PKG 5.) cd into $ABSROOT/$ABSREPO/$PKG 6.) customizepkg --modify 7.) makepkg (copy from the aur function) 8.) pacman -U resulting-pkg-file.tar.xz

do you have a better way? ideally, step 2.b and step 4 can be merged into the same function i'd imagine. you can also separate out steps 6-8 into a separate function as well, as they can be shared for both AUR builds and customizepkg'd pacman packages. is there a cleaner way of doing this?

oshazard commented 9 years ago

@bts368 I just wanted to let you know that building ABS packages isn't a high priority for me right now, so I'm sorry. I've got other projects that need my attention and I don't know when I'll get around to it, so you may want to look elsewhere.

ghost commented 9 years ago

@oshazard no worries! it was mostly a suggestion to balance it out, and i totally understand; i've been pretty busy myself! i keep hoping to find time to implement this funtionality and don't seem to get the chance.