FS#1588 - makepkg templates/classes
Attached to Project:
Pacman
Opened by Jan de Groot (JGC) - Tuesday, 05 October 2004, 14:20 GMT
Last edited by Allan McRae (Allan) - Saturday, 04 August 2012, 03:04 GMT
Opened by Jan de Groot (JGC) - Tuesday, 05 October 2004, 14:20 GMT
Last edited by Allan McRae (Allan) - Saturday, 04 August 2012, 03:04 GMT
|
Details
I recently switched to gentoo, and what I seriously like in
gentoo is the eclass thing they use:
a gnome package just uses inherit gnome2, and that one takes care of downloading the right source from a ftp.gnome.org mirror, does the gconf registration, does the freedesktop.org mime registration and does the scrollkeeper-update thing. When I took a look at those, I think archlinux could use something like that too for KDE and gnome packages, or even more packages related to eachother. Why have 100 .install files in /var/abs having the same instructions in it, but having a different name? For gnome-common for example, we could have one file that has some functions, like register_gconf or update_scrollkeeper, then every gnome package that has a postinstall that needs them, just sources the gnome-common script and executes the stated functions, or even better, let gnome-common's script run the statements on inclusion (a script can detect whether it's included or not). This would take some load off of the maintainers, since when archlinux changes some policy, it has to be updated in one place, not in something like 100 different .install files. |
This task depends upon
Closed by Allan McRae (Allan)
Saturday, 04 August 2012, 03:04 GMT
Reason for closing: None
Additional comments about closing: Superseded
Saturday, 04 August 2012, 03:04 GMT
Reason for closing: None
Additional comments about closing: Superseded
I mean, right now, we could already just "source ../gnomebaker/PKGBUILD" at the top of a PKGBUILD, or even just make an "inherit gnomebaker" function or something.
I have slightly different ideas for "on install" functionality which would make that portion of this request obsolete.
- several variables defined on make install for gconf
- there's always a find/sed over makefiles, or a --disable-scrollkeeper (do both to be sure :P)
- there's always a gconf-merge-schema command
- there's always something that sources /etc/profile.d/gnome.sh
then the .install files:
- always run gconftool-2 schema install/uninstall on post_upgrade, remove, install and the pre_ versions of those
- always run scrollkeeper-update
- always run gtk-icon-update for hicolor icon theme files
- always run update-desktop-database for apps with .desktop files
These are very common things that could be included in some kind of macro file. For gconf, a lot of things are made much more simple with the new gconf script I wrote for gnome 2.14, we could either have more of those scripts, or make it some macro-specific something.
About the eclasses: the whole ebuild is just on install, so that is true for the eclasses also. They build specific things for your system, we have to make a binary that's always the same, no matter how you build it.
For the "on install" feature, I mean the things we put in .install files. Both things have their advantages and disadvantages. If we make it "include on install", then we have to make sure that an ancient package built somewhere in 2004 would still install file with rulesets from the gconf package dated in 2006. If we just copy over some template stuff, this can be avoided, but adds more trouble when something in the "template" is plain wrong.
Running scripts after update is more hooks territory, which is covered by
FS#2985. Adding helper functions is covered byFS#10375which asks for support for adding a library to makepkg.