You are not logged in.
Eschwartz wrote:It should also be possible to automatically compile python bytecode, rather than depending on maintainers to necessarily take care of it (could be extended by maintainers packaging modules outside /usr/lib/python*/)... as well as decreasing the size of packages which no longer have to track pyc/pyo files.
I hope not. Preferably, everything in /usr (except /usr/local) should be tracked by the package manager. It just makes things simpler. Hooks are useful for things that can't be done at compile time (i.e. things that depend on the state of the machine on which the package is being installed).
/usr/share has a bunch of things like that...
/usr/share/mime/
/usr/share/applications/mimeinfo.cache
/usr/share/icons/*/icon-theme.cache
/usr/share/fonts/*/fonts.{scale,dir}
/usr/share/vim/vimfiles/doc/tags
Just a few things which pkg-list_unpackaged_files reports for me.
...
Now, there may be reasons to avoid compiling bytecode through hooks.
But the purity of /usr is not one of them. (Purity of /usr/lib? Now you're talking business...)
I have heard the suggestion of doing so for the sake of space saving in the repositories. It isn't a ridiculous idea -- we are talking about a cache here. Assuming any theoretical hook can clean up orphaned pyc files, I don't actually see the harm.
It may not ultimately be an idea that people gather around, granted. But either way, I am merely repeating something I heard someone else say, as food for thought...
Last edited by eschwartz (2016-01-18 17:20:45)
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
/usr/share has a bunch of things like that...
/usr/share/mime/
/usr/share/applications/mimeinfo.cache
/usr/share/icons/*/icon-theme.cache
/usr/share/fonts/*/fonts.{scale,dir}
/usr/share/vim/vimfiles/doc/tagsJust a few things which pkg-list_unpackaged_files reports for me.
Most of those are things that can't really belong to a single package. If they can, they should.
Offline
Nice! This makes sense to me now, thanks posting.
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
apg wrote:Nice! This makes sense to me now, thanks posting.
Actually, back-track a bit. I recall reading (can't find the link) that hooks can make dkms packages and module-only packages (eg nvidia, virtualbox, etc.) obsolete. Is there any official inertia to move in this direction when 5.0 does go into [core]? Specifically, a systematic replacement of the aforementioned packages in favor of a corresponding hook?
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
Offline
Offline
Nice
So long as there's a hook that prints out "Arch is the best" after each individual package upgrade, I'll be happy.
Well, not after each idividual package ... but it's a start.
[Trigger]
Operation = Install
Operation = Upgrade
Operation = Remove
Type = Package
Target = *
[Action]
Description = Arch is the best!
When = PostTransaction
Exec = /usr/bin/bash
Offline
Exec = /usr/bin/bash
not the best idea... try /bin/true instead.
Offline
Ah, didn't know that...
Seriously: It's really nice to have the hooks.
And thanks to all the devs and community for the great work on Arch.
EDIT: Since it's in [testing] now, I'll mark the thread as solved.
Last edited by michis (2016-01-30 12:56:38)
Offline