Does decpac handle AUR?

[rendaw]

Does decpac handle AUR?

[rendaw]

Yeah! If you put a (aur) in front of the package name it installs from AUR. I'm currently piggybacking on 3rd party AUR helpers though so you need to specify a aur helper command line in decpac.conf.

In any case I'll add a note to the readme.

I should also probably add some info on the config file format, even though it's automatically generated.

This is very proof of conceptish right now, but I've been using it myself for a couple months. I think it may be a good idea to actually implement an aur helper here rather than shell out... the existing helpers had a lot of issues with dependencies, marking packages, etc. After trying a couple helpers I settled on trizen on my system but had to work around some stuff. Also it would be cool to support ruby/node packages using npm2arch and similar tools.

If you end up writing your own version let me know and I'll link it here. Nobody's using this other than me AFAIK :P

[rendaw]

Also, just realized I hadn't pushed a bunch of changes; pushed now.

[rendaw]

Oops, actually looks like have a git config issue. Will push in a few minutes in any case.

[atomicwrites]

OK, thanks. I saw your answer this morning but didn't have time to reply, but I've been thinking about the AUR helper. This would probably a good idea, there is a python library available (which I haven't used) at Kwpolska/pkgbuilder that has functions to find outdated AUR packages, create dependencies lists, search the AUR, etc. It seems somewhat mature, is actually documented, and has activity on the repo. It may be good for avoiding the heavy lifting, but I'm not sure how complex the AUR api is. I would like to help out if I can get time, I've got a lot of schoolwork right now. I noticed ther's no license, without a license no one can use your code legally so you might want to fix that. If you have no personal preference go with MIT, if you want you can always re-release later under a different license as the author.

I also used CyberShadow/aconfmgr and while it's nice to have your config files be under version control as well like in NixOS so you can restore them along with your packages, every time you do save or apply it takes around 8 minutes (on my laptop with a mid-range spinny drive) to scan for files that have changed from the version in the package, so its useless as a package manager. Still useful for backing up thou. Do you have any interest in extending decpac to handle configs in the future, somewhat like nix? Obviously not in the sense of re implementing the nix config language but simply keeping copies of files you edit manually and watching them for changes, kind of like aconfmgr but not horribly slow, this might work by just watching the files the user specifies, or something more clever. I just noticed how long this got, well I'm off to test out decpac. I was meaning to migrate to lvm so when I do I'll test both decpac and aconfmgr in setting up a new system.

[rendaw]

Ah, thanks for the note! I actually have MIT in setup.py but I forgot to add the license text to the repo. Doing that shortly.

And https://github.com/Kwpolska/pkgbuilder looks great! I'm going to play around with it. I think as long as it can give me dependencies the rest should be pretty simple; I just didn't want to have to parse the build files, but if it helps building too that would be really helpful.

Someone actually just pinged me yesterday about aconfmgr as well here: https://bbs.archlinux.org/viewtopic.php?pid=1780355#p1780355 . It's interesting that it takes 8 minutes, although I have no idea how complex the code for managing configs and everything is. TBH I was initially planning to cache some values in decpac but running pacman to check what's installed ended up being quick and more precise so I dropped the cache, but if you have issues with decpac's speed I think there's room for optimization.

[atomicwrites]

Decpac is nearly instantaneous for me, that's not an issue. What happens with aconfmgr is that as far as I can tell it extracts every package on your system one by one and compares it's files to the files on your disk to find the ones that have been modified. After that it removes the files in your ignore list from the list of changed files. So it does things backwards and in a very ineficient way. My ideal implementation, which is completely untested, would be to do this based on the pacman database. It already read which files should be saved across upgrades or on uninstall (hence .pacnew and .pacsave files) and the wiki gives this command to query the database for changed files labeled for backup: pacman -Qii | awk '/^MODIFIED/ {print $2}'. On my system this prints:

/etc/cups/printers.conf
/etc/cups/cups-pdf.conf
/etc/fstab
/etc/group
/etc/gshadow
/etc/hosts
/etc/passwd
/etc/profile
/etc/resolv.conf
/etc/shadow
/etc/shells
/etc/locale.gen
/etc/mkinitcpio.conf
/etc/ssh/sshd_config
/etc/pacman.conf
/etc/makepkg.conf
/etc/pacman.d/mirrorlist
/etc/pmount.allow
/etc/conf.d/snapper
/etc/sudoers
/etc/texmf/web2c/fmtutil.cnf

Which is probably everything I care about and takes a fraction of a second. (See: https://wiki.archlinux.org/index.php/Pacman/Tips_and_tricks#Listing_changed_backup_files)

[atomicwrites]

Also, especially since decpac will be installing tones of packages together, it would be good to batch everything the user has to confirm at the beginning. This is what annoys me the most about most AUR helpers that compiling takes a long time but you have to watch it to accept prompts for each package. Also, a pitfall to keep in mind is GPG keys. aconfmgr crashes if a package uses GPG.

I've been thinking that the config management would likely be better as a separate program (maybe recommended for each other?).

[rendaw]

Oh, that's a good idea. I didn't realize those files were tracked, but it makes sense, and that looks like a good list.

TBH I haven't thought too much about config files so it would be hard for me to decide on what sort of functionality would be good to have in decpac in that regard. I thought that managing them with git would be cool maybe, but I haven't started on it yet and I'm not sure what tools I'd need if any aside from git.

it would be good to batch everything the user has to confirm at the beginning

Agreed. Actually, I think decpac does this (for all it's own prompts) but the AUR helpers and stuff might have their own prompts if you don't add --dont-confirm or something.

One other problem is you need to prompt for sudo credentials at the end (after building all packages)... I usually start installing stuff then switch desktops to work on other things and forget about it, then the sudo prompt times out and I have to rebuild everything :P .

I've been thinking that the config management would likely be better as a separate program (maybe recommended for each other?).

I'm interested in what the config management program would be like. I'd be glad to link to something you made though in the readme, and if I can modify decpac to make integration easier somehow I'd give it a try!

[atomicwrites]

I haven't worked everything out but my current idea borrows from stow (which I use for my dotfiles and works well). It would take the list from pacman (by the way it doesn't show everything if you don't run it as root, for example the shadow file is missing), pass it to pacman -Qoq and zip the result. This gives you a list of files and their package. Make a folder at /etc/savepac/files/ (terrible working name) for each package in the file lost, plus one for custom files added in a config file. Then copy the files in the list into the folder for each package, so /etc/fstab would go to /etc/savepac/files/filesystem/etc/fstab (filesystem is the package that owns fstab, passwd, etc.) and make /etc/fstab a symlink. This is stow-compatible, so you could do stow -d /etc/savepac/files -t / filesystem and use your files without installing savepac. There is also optionally a /etc/savepac/old/ dir where each time it looks for files or on first run it checks if the files have changed and copy of the files/ tree in a timestamped dir so that to swap to an old version of your files you just unstow the current one and stow an old version. I would probably ad an interface to the old version system. This is optional because git version control might be enough for someone, and it would be super simple to add a config option for a post-run hook which you can use to commit files if you don't want to use built in versioning. I thought of using hardlinks to make it incremental like rsnapshot/timeshift/a ton of other rsync based backup programs but decided it wasn't worth it since these are tiny files, but if someone wants to the can use the hook I mentioned to use a utility that deduplicates. Another big aconfmgr problem this doesn't have is that with aconfmgr, if you don't ignore shadow and other sensitive files they wind up in your home dir with your permissions, with this method they stay in /etc and I copy permissions and owner so it's safe, well as safe as your backup is.

A trick to use sudo in scripts is to run sudo -v in a loop in the background with a couple minute pause between each invocation. This keeps your authentication from timing out.

-v

When given the -v (validate) option, sudo will update the user's cached credentials, authenticating the user's password if necessary. For the sudoers plugin, this extends the sudo timeout for another 5 minutes (or whatever the timeout is set to in sudoers) but does not run a command

Sorry for the wall of text.