[arch-general] Need help understanding meta-PKGBUILDs
Guys, We have made good progress refining the basics for Trinity PKGBUILDs. The trinity/dependencies PKGBUILDs are working for tqtinterface and arts. https://wiki.archlinux.org/index.php/Trinity#Development_PKGBUILDs They have been reworked to conform with the kde4 (kde-meta) PKGBUILD structure. But, I'm having trouble understanding how to 'tie' the meta-PKGBUILDs together with the actual PKGBUILDs for the individual trinity modules. Here are the questions I have: (1) can I have 3-levels of PKGBUILDs? Example: the trinity directory structure is: trinity applications dependencies arts tqtinterface <snip> Following the kde4 layout, I was trying to create something like this: trinity <PKGBUILD pkgbase=trinity-meta> applications dependencies <PKGBUILD pkgbase=trinity-meta> arts <PKGBUILD pkgbase=trinity> tqtinterface <snip> I have the arts and tqtinterface level PKGBUILDs done, but I don't know how to tie them to the trinity-meta PKGBUILDs above. Looking at the kde4 examples, I have the following: under trinity: pkgbase=trinity-meta pkgname=('trinity-meta-applications' 'trinity-meta-dependencies' <snip> package_trinity-meta-applications() { <snip> } package_trinity-meta-dependencies() { pkgdesc=('Meta package for trinity-dependencies') depends=('cmake' 'python2-sip' 'pyqt3' 'pykde3' 'qt3') replaces=('trinity-dependencies') conflicts=('trinity-dependencies') } under trinity/dependencies: pkgbase=trinity-meta pkgname=('trinity-meta-tqtinterface' 'trinity-meta-arts') pkgver=$(getsvnrev) pkgrel=1.0 arch=('i686' 'x86_64') url='http://www.kde.org' license=('GPL') groups=('trinity' 'trinity-bld') package_trinity-meta-tqtinterface() { pkgdesc=('Meta package for dependencies-tqtinterface') depends=('cmake' 'python2-sip' 'pyqt3' 'pykde3' 'qt3') replaces=('tqtinterface') conflicts=('tqtinterface') } package_trinity-meta-arts() { pkgdesc=('Meta package for dependencies-arts') depends=('cmake' 'python2-sip' 'pyqt3' 'pykde3' 'qt3' 'tqtinterface') replaces=('trinity-arts') conflicts=('trinity-arts') } under trinity/dependencies/arts: http://www.3111skyline.com/dl/dt/trinity/arch/dev/dependencies/arts/PKGBUILD under trinity/dependencies/tqtinterface: http://www.3111skyline.com/dl/dt/trinity/arch/dev/dependencies/tqtinterface/... What I don't understand is how does calling the trinity level PKGBUILD invoke the trinity/dependencies level PKGBUILD and so on.... (2) I googled using arch meta pkgbuild, but I haven't come up with a good reference. Does anyone have a good link or reference? https://wiki.archlinux.org/index.php/PKGBUILD, https://wiki.archlinux.org/index.php/Creating_Packages and https://wiki.archlinux.org/index.php/Makepkg don't really explain it. (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 they need improving. Thanks. -- David C. Rankin, J.D.,P.E.
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 they need improving. Thanks.
Just a note. In addition to the tqtinterface and trinity-arts, 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.
On 2 February 2011 01:10, David C. Rankin <drankinatty@suddenlinkmail.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 they need improving. Thanks.
Just a note. In addition to the tqtinterface and trinity-arts, 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
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 <drankinatty@suddenlinkmail.com> 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 2 February 2011 13:25, Thomas S Hatch <thatch45@gmail.com> 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 <drankinatty@suddenlinkmail.com> 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
On Wed, Feb 2, 2011 at 11:46 AM, Tavian Barnes <tavianator@tavianator.com>wrote:
On 2 February 2011 13:25, Thomas S Hatch <thatch45@gmail.com> 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 <drankinatty@suddenlinkmail.com> 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)
Tavian Barnes wrote:
On 2 February 2011 01:10, David C. Rankin <drankinatty@suddenlinkmail.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 they need improving. Thanks. Just a note. In addition to the tqtinterface and trinity-arts, 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.
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. Jerome -- mailto:jeberger@free.fr http://jeberger.free.fr Jabber: jeberger@jabber.fr
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.
participants (4)
-
"Jérôme M. Berger"
-
David C. Rankin
-
Tavian Barnes
-
Thomas S Hatch