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
Task Type Feature Request
Category
Status Closed
Assigned To Aaron Griffin (phrakture)
Architecture not specified
Severity Low
Priority Normal
Reported Version 0.7 Wombat
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

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
Comment by Aaron Griffin (phrakture) - Thursday, 28 April 2005, 23:19 GMT
Sounds like a very hefty change, but makes sense - perhaps an installation "registry" where different installation schemes are kept... i.e. "on-install=(update-scrollkeeper,update-gconf)" - where those two would be scripts, and installed by parent packages
Comment by arjan timmerman (blaasvis) - Thursday, 23 March 2006, 11:30 GMT
are you one day gonna do this ?
Comment by Aaron Griffin (phrakture) - Monday, 27 November 2006, 18:04 GMT
gentoo eclasses are _just_ for install, correct? or are you talking about inheriting PKGBUILDs as well?

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.
Comment by Jan de Groot (JGC) - Monday, 27 November 2006, 18:26 GMT
If you take a look at the PKGBUILDs in extra/gnome, you'll find some generic things there:
- 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.
Comment by Allan McRae (Allan) - Saturday, 04 August 2012, 03:03 GMT
No comments in six years! Time to close...

Running scripts after update is more hooks territory, which is covered by  FS#2985 . Adding helper functions is covered by  FS#10375  which asks for support for adding a library to makepkg.

Loading...