[arch-general] PKGBUILD - howto handle 'src' when svn source is already in PKGBUILD dir?
Guys, I'm trying to figure out the best way to create a set of PKGBUILDs for the Trinity svn tree. I already have the svn source on my computer. I can check for the latest version or svn up each module and I can have makepkg 'redownload' the latest rev in $startdir/src, but HOW do I setup the PKGBUILD to just use what is already in the svn tree? Example: arts I have the following in the dependencies/arts directory: .svn admin artsc cmake doc examples flow gmcop libltdl mcop mcop_mt mcopidl qtmcop soundserver tests x11 CMakeLists.txt COPYING COPYING.LIB INSTALL Makefile.am.in Makefile.cvs arts.lsm arts.pc.cmake config.h.cmake configure.in.bot configure.in.in Since I already have the source, I don't want to create a new $startdir/src/arts under the dependencies/arts directory by simply calling makepkg in that directory. (unless there is some out-of-source trick using links or the like) I'd like to find a way to just do a PKGBUILD to use the source in the current directory and then create the pkg directory in another location. Is there a standard way of handling PKGBUILDs for each module in a large tree that can do this? It's almost like I want to use --noextract while creating a link from src -> ./, but that just seems screwy. Anybody got a trick for doing this? -- David C. Rankin, J.D.,P.E.
On Fri, Jan 28, 2011 at 7:57 AM, David C. Rankin < drankinatty@suddenlinkmail.com> wrote:
Guys,
I'm trying to figure out the best way to create a set of PKGBUILDs for the Trinity svn tree. I already have the svn source on my computer. I can check for the latest version or svn up each module and I can have makepkg 'redownload' the latest rev in $startdir/src, but HOW do I setup the PKGBUILD to just use what is already in the svn tree?
Example: arts
I have the following in the dependencies/arts directory:
.svn admin artsc cmake doc examples flow gmcop libltdl mcop mcop_mt mcopidl qtmcop soundserver tests x11 CMakeLists.txt COPYING COPYING.LIB INSTALL Makefile.am.in Makefile.cvs arts.lsm arts.pc.cmake config.h.cmake configure.in.bot configure.in.in
Since I already have the source, I don't want to create a new $startdir/src/arts under the dependencies/arts directory by simply calling makepkg in that directory. (unless there is some out-of-source trick using links or the like) I'd like to find a way to just do a PKGBUILD to use the source in the current directory and then create the pkg directory in another location. Is there a standard way of handling PKGBUILDs for each module in a large tree that can do this?
It's almost like I want to use --noextract while creating a link from src -> ./, but that just seems screwy. Anybody got a trick for doing this?
-- David C. Rankin, J.D.,P.E.
See how this is handled e.g. in this PKGBGUILD: https://aur.archlinux.org/packages/mesa-git/mesa-git/PKGBUILD -- Kirill Churin Jabber: reflexing@reflexing.ru, ICQ: 8163230, Skype on demand.
On 01/28/2011 02:57 AM, Kirill Churin wrote:
See how this is handled e.g. in this PKGBGUILD: https://aur.archlinux.org/packages/mesa-git/mesa-git/PKGBUILD
Thank you Kirill! So it looks like I need to backup one (or two) directories and do the PKGBUILD higher up in the svn tree rather than on a 'per module' basis. Is there a general rule of thumb to figure out where to put it? Take for example the svn tree: applications abakus adept amarok basket <snip> dependencies arts tqtinterface kdeaccessibility kdeaddons kdeadmin <snip> looking at mesa, they do the PKGBUILD at the top, build everything, then 'package' the various pieces (modules) individually. What is the thought process for determining whether you put one PKGBUILD at the top and do it like mesa or whether you put one PKGBUID in each major module and build from there? Example: applications PKGBUILD dependencies PKGBUILD kdeaccessibility PKGBUILD <snip> Is it just a 'whatever makes the PKGBUILD' setup work best? Or are there some fast and hard rules like a 'one subdirectory limit' that I need to know? Thanks Again. -- David C. Rankin, J.D.,P.E.
On Fri, Jan 28, 2011 at 9:02 PM, David C. Rankin < drankinatty@suddenlinkmail.com> wrote:
On 01/28/2011 02:57 AM, Kirill Churin wrote:
See how this is handled e.g. in this PKGBGUILD: https://aur.archlinux.org/packages/mesa-git/mesa-git/PKGBUILD
Thank you Kirill!
So it looks like I need to backup one (or two) directories and do the PKGBUILD higher up in the svn tree rather than on a 'per module' basis. Is there a general rule of thumb to figure out where to put it? Take for example the svn tree:
applications abakus adept amarok basket <snip> dependencies arts tqtinterface kdeaccessibility kdeaddons kdeadmin <snip>
looking at mesa, they do the PKGBUILD at the top, build everything, then 'package' the various pieces (modules) individually. What is the thought process for determining whether you put one PKGBUILD at the top and do it like mesa or whether you put one PKGBUID in each major module and build from there? Example:
applications PKGBUILD dependencies PKGBUILD kdeaccessibility PKGBUILD <snip>
Is it just a 'whatever makes the PKGBUILD' setup work best? Or are there some fast and hard rules like a 'one subdirectory limit' that I need to know?
Thanks Again.
-- David C. Rankin, J.D.,P.E.
Why don't you look how do KDE packages currently handled in Arch? I think you can apply it's basic principles to your Trinity packages as well. E.g. http://projects.archlinux.org/svntogit/packages.git/tree/kde-meta/trunk/PKGB... and it's deps… <http://projects.archlinux.org/svntogit/packages.git/tree/kde-meta/trunk/PKGBUILD> -- Kirill Churin Jabber: reflexing@reflexing.ru, ICQ: 8163230, Skype on demand.
On 01/28/2011 10:40 AM, Kirill Churin wrote:
Why don't you look how do KDE packages currently handled in Arch? I think you can apply it's basic principles to your Trinity packages as well.
E.g. http://projects.archlinux.org/svntogit/packages.git/tree/kde-meta/trunk/PKGB... and it's deps… <http://projects.archlinux.org/svntogit/packages.git/tree/kde-meta/trunk/PKGBUILD>
That looks like the way to go. I can follow what it does, but I'm missing how the kde-meta/PKGBUILD actually invokes the module PKGBUILDs (eg. kdebase). For example, in kde-meta, I see: pkgbase=kde-meta pkgname=('kde-meta-kdeaccessibility' 'kde-meta-kdeadmin' 'kde-meta-kdeartwork' 'kde-meta-kdebase' <snip> package_kde-meta-kdebase() { pkgdesc=('Meta package for kdebase') depends=('kdebase-dolphin' 'kdebase-kdepasswd' 'kdebase-kdialog' 'kdebase-kfind' 'kdebase-keditbookmarks' 'kdebase-konqueror' 'kdebase-konsole' 'kdebase-kwrite' 'kdebase-plasma') replaces=('kdebase') conflicts=('kdebase') } Then in the kdebase/PKGBUILD I see: pkgbase=kdebase pkgname=('kdebase-dolphin' 'kdebase-kdepasswd' 'kdebase-kdialog' 'kdebase-keditbookmarks' <snip> build()... <snip> package_kdebase-dolphin() { pkgdesc='File Manager' depends=('kdebase-runtime' 'kdebase-lib') optdepends=('ruby: servicemenu installation') url="http://kde.org/applications/system/dolphin/" <snip> But what I don't get is where is the magic that ties the kde-meta/PKGBUILD to the kdebase/PKGBUILD? I can't see where the kde-meta script calls anything to trigger a build. Is there some magic in the 'package_' prefix, or, is it just a road-map that gets read by a script that subsequently loops through the actual kde/modules calling makepkg -s for each module? Thanks for any help you can provide. -- David C. Rankin, J.D.,P.E.
participants (2)
-
David C. Rankin
-
Kirill Churin