On Wed, Feb 2, 2011 at 11:19 AM, Tavian Barnes wrote:

...

On 02/01/2011 10:41 PM, David C. Rankin wrote:

...

(3) Lastly, if anybody has interest, please look over the PKGBUILDs and let me know where I'm doing something stupid. I have done quite a bit of reading trying to digest PKGBUILDs and how to apply them to a large project like Trinity. I don't claim to be an expert on them, so I know there are places where

...

...

improving. Thanks.

Just a note. In addition to the tqtinterface and trinity-arts,

On 2 February 2011 01:10, David C. Rankin wrote: they need trinity-kdelibs

...

PKGBUILD is now working and open for comment:

http://www.3111skyline.com/dl/dt/trinity/arch/dev/kdelibs/PKGBUILD

so far so good -- a little PKGBUILD knowledge... is a dangerous thing :P

-- David C. Rankin, J.D.,P.E.

I don't see why you need meta packages; groups should do fine. I think the only reason that Arch's meta packages exist is to provide an upgrade path from the pre-splitpkg KDE days.

-- Tavian Barnes

Do groups register in AUR packages? My understanding is that they do not because there is no repo metadata. Then I would say that metapackages for large AUR builds like this one would be the way to go, but to keep the group info in so that if in the future this all moves to community then we are ready for it. Unless of course there is group magic that I don't know about!

On Wed, Feb 2, 2011 at 11:46 AM, Tavian Barnes wrote:

On 2 February 2011 13:25, Thomas S Hatch wrote:

...

On Wed, Feb 2, 2011 at 11:19 AM, Tavian Barnes < tavianator@tavianator.com>wrote:

...

...

On 02/01/2011 10:41 PM, David C. Rankin wrote:

...

(3) Lastly, if anybody has interest, please look over the PKGBUILDs and let me know where I'm doing something stupid. I have done quite a bit of reading trying to digest PKGBUILDs and how to apply them to a large project like Trinity. I don't claim to be an expert on them, so I know there are places where

...

...

improving. Thanks.

Just a note. In addition to the tqtinterface and trinity-arts,

On 2 February 2011 01:10, David C. Rankin wrote: they need trinity-kdelibs

...

PKGBUILD is now working and open for comment:

http://www.3111skyline.com/dl/dt/trinity/arch/dev/kdelibs/PKGBUILD

so far so good -- a little PKGBUILD knowledge... is a dangerous thing :P

-- David C. Rankin, J.D.,P.E.

I don't see why you need meta packages; groups should do fine. I think the only reason that Arch's meta packages exist is to provide an upgrade path from the pre-splitpkg KDE days.

-- Tavian Barnes

Do groups register in AUR packages? My understanding is that they do not because there is no repo metadata. Then I would say that metapackages for large AUR builds like this one would be the way to go, but to keep the group info in so that if in the future this all moves to community then we are ready for it.

Unless of course there is group magic that I don't know about!

Um, I don't see how meta packages help for the AUR either, you've still got to download all their dependencies.

-- Tavian Barnes

It would help with tools like yaourt and clyde, unless those do group detection (If they do I don't know about it)

On 02/02/2011 02:52 PM, "Jérôme M. Berger" wrote:

...

I don't see why you need meta packages; groups should do fine. I

...

think the only reason that Arch's meta packages exist is to provide an upgrade path from the pre-splitpkg KDE days.

Except that when you install a group, if a package gets added to the group later it will not be automatically installed when you upgrade. With a meta-package it will.

Tavian, Thomas, Jérôme, Thank you. This information is helpful. Currently there are two groups: trinity-bld (for the build dependencies that are not part of Trinity) trinity (for the trinity modules -- eg. trinity-art, trinity-kdelibs) The current module pkgbuilds are looking similar to this (kdelibs): getsvnrev() { msg "Determining SVN revision for $pkgname..." [[ -d .svn ]] && echo $(svnversion .) || echo 9999 } pkgbase=trinity pkgname=trinity-kdelibs pkgver=$(getsvnrev) pkgrel=1.0 arch=('i686' 'x86_64') url='http://www.kde.org' license=('GPL') groups=('trinity') pkgdesc="Trinity - kdelibs" depends=('qt3' 'pyqt3' 'python2-sip' 'pykde3' 'tqtinterface' 'trinity-arts') makedepends=('pkgconfig' 'cmake' 'autoconf') provides=('trinity-kdelibs') conflicts=('trinity-kdelibs') replaces=('trinity-kdelibs') source=() build() { msg "Configuring autotools and Creating Makefile.common" cd ${startdir} cp -Rp /usr/share/aclocal/libtool.m4 admin/libtool.m4.in cp -Rp /usr/share/libtool/config/ltmain.sh admin/ltmain.sh make -f admin/Makefile.common # set --enable-closure configure option if needed (not needed for kdelibs) trinity_prefix="/opt/trinity" ./configure --prefix=${trinity_prefix} \ --includedir=${trinity_prefix}/include/kde \ --mandir=${trinity_prefix}/share/man \ --infodir=${trinity_prefix}/share/info \ --with-extra-libs=${trinity_prefix}/lib \ --sysconfdir=/etc \ --localstatedir=/var \ --libexecdir=${trinity_prefix}/lib/kdebase-kde3 \ --with-qt-dir=/opt/qt \ --with-qt-includes=/opt/qt/include \ --with-qt-libraries=/opt/qt/lib \ --with-extra-includes=/opt/qt/include/tqt \ --disable-rpath cd ${srcdir} cmake ../ \ -DCMAKE_INSTALL_PREFIX=${trinity_prefix} \ -DWITH_QT3=ON \ -DCMAKE_SKIP_RPATH=ON make } package() { msg "Packaging - $pkgname-$pkgver" make DESTDIR="$pkgdir/" install } As posted in the original thread, I have modeled meta-PKGBUILDs on the kde4 scripts, but don't really understand how they fit into the overall picture. Since we are still slogging through the actual PKGBUILDs for the trinity modules, we will have plenty of time to think about the meta-PKGBUILDs. Let me know if there is something I need to add to the basic PKGBUILD layout to make them more compatible with a meta setup. (better to add now than have to go back and edit all of them later) -- David C. Rankin, J.D.,P.E.