providing splitted KDE packages is one of most wanted feature request sine
there was KDE in Arch. And people have good reasons demanding it. Let's have a
look at the problem:
The KDE project does not provide source packages for every single application
but they put them in some kind of categories. E.g. there are kdenetwork,
kdemultimedia, kdegraphics etc.. So if you want an VNC client you have to
install kdenetwork and you'll get an instant messanger, download manager, nvc
server, samba client and others including their dependencies for free.
But there is hope: future versions of makepkg will be able to help splitting
those packages in an easy way: http://dev.archlinux.org/~allan/makepkg-
git.html In fact KDE ist already prepared to be splitted; all you need to do
is running make install in the right directory.
After 4.2 will hit [extra] I'd like to work on this. This will also be a good
test case for the makepkg implementation.
In addition to this we'll need to update our devtools and db-scripts to handle
those packages right. extrapkg should be quite simple; archrelease and repo-
add should work just fine; only the db-scripts will really fail because they
cannot guess the svn-dir just from the package name anymore.
My idea of splitting is to create one package for each app like kopete and not
split by data, lib, docs etc.. Those packages will be members of a group; so
pacamn -S kdenetwork still results in the same apps being installed.
And last but not least: You might wonder why we not just include kdemod. I had
a little talk with funkyou about this. KDEmod/Chakra has different goals and
philosophy and is not really compatible with the Arch way. So they'd like to
keep doing their own thing.
Greetings,
Pierre
PS: I have attached a quick&dirty example to just show you that this would not
increase complexity that much; indeed I think this makes things a lot cleaner.
--
Pierre Schmitz
Clemens-August-Straße 76
53115 Bonn
Telefon 0228 9716608
Mobil 0160 95269831
Jabber pierre@jabber.archlinux.de
WWW http://www.archlinux.de
# $Id: PKGBUILD 24460 2009-01-17 13:41:39Z andrea $
# Maintainer: Pierre Schmitz <pierre@archlinux.de>
build() {
cd $srcdir
mkdir build
cd build
cmake ../kdenetwork-${pkgver}
-DCMAKE_BUILD_TYPE=Release
-DCMAKE_INSTALL_PREFIX=/usr
-DWITH_Xmms=OFF
make
}
package_filesharing() {
pkgdesc='network file sharing'
depends=('kdebase-runtime' 'kdelibs')
install='kdenetwork.install'
cd $srcdir/build/filesharing
make DESTDIR=$pkgdir install
}
package_kdnssd() {
pkgdesc='Zeroconf'
depends=('kdebase-runtime' 'kdelibs')
cd $srcdir/build/kdnssd
make DESTDIR=$pkgdir install
}
package_kget() {
pkgdesc='an advanced download manager'
depends=('kdebase-workspace' 'kdebase' 'qca')
install='kdenetwork.install'
cd $srcdir/build/kget
make DESTDIR=$pkgdir install
cd $srcdir/build/doc/kget
make DESTDIR=$pkgdir install
}
package_kopete() {
pkgdesc='Instant Messaging client'
depends=('kdebase-runtime' 'kdepimlibs' 'qca' 'libotr' 'libmsn' 'libidn' 'libxss' 'qimageblitz')
install='kdenetwork.install'
cd $srcdir/build/kopete
make DESTDIR=$pkgdir install
cd $srcdir/build/doc/kopete
make DESTDIR=$pkgdir install
}
#
# package_kppp() {
# pkgdesc='dialer and front end for pppd'
# depends=('kdebase-runtime' 'kdelibs' 'ppp')
# install='kdenetwork.install'
# cd $srcdir/build/kppp
# make DESTDIR=$pkgdir install
# cd $srcdir/build/doc/kppp
# make DESTDIR=$pkgdir install
# }
package_krdc() {
pkgdesc='a client for Desktop Sharing'
depends=('kdebase-runtime' 'kdelibs' 'libvncserver' 'rdesktop')
cd $srcdir/build/krdc
make DESTDIR=$pkgdir install
cd $srcdir/build/doc/krdc
make DESTDIR=$pkgdir install
}
package_krfb() {
pkgdesc='Desktop Sharing server, allow others to access your desktop via VNC'
depends=('kdebase-runtime' 'kdelibs' 'libvncserver' 'libxdamage')
cd $srcdir/build/krfb
make DESTDIR=$pkgdir install
cd $srcdir/build/doc/krfb
make DESTDIR=$pkgdir install
}
01-23-2009, 12:00 AM
Aaron Griffin
Divide and Konquer - Splitting KDE packages
On Thu, Jan 22, 2009 at 6:21 PM, Pierre Schmitz <pierre@archlinux.de> wrote:
> In addition to this we'll need to update our devtools and db-scripts to handle
> those packages right. extrapkg should be quite simple; archrelease and repo-
> add should work just fine; only the db-scripts will really fail because they
> cannot guess the svn-dir just from the package name anymore.
Hmmm, this one I will have to think about. The devtools changes should
be straightforward, but the db-scripts changes will not. Any ideas as
to how we can convert a packagename to an svn-dir name? I'd rather not
scan the whole repo...
> And last but not least: You might wonder why we not just include kdemod. I had
> a little talk with funkyou about this. KDEmod/Chakra has different goals and
> philosophy and is not really compatible with the Arch way. So they'd like to
> keep doing their own thing.
That's great. I love the kdemod guys - they have all the spirit and
spunk that satellite projects should have. Can we make sure we stay in
a... complementary mode, rather than try to compete with them? I don't
know if this would be doing anything that would step on their toes or
not, but it'd be really nice not to discourage them. I'm not a KDE
user, but I hear nothing but great things about kdemod
01-23-2009, 12:35 AM
Aaron Griffin
Divide and Konquer - Splitting KDE packages
On Thu, Jan 22, 2009 at 7:00 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
> On Thu, Jan 22, 2009 at 6:21 PM, Pierre Schmitz <pierre@archlinux.de> wrote:
>> In addition to this we'll need to update our devtools and db-scripts to handle
>> those packages right. extrapkg should be quite simple; archrelease and repo-
>> add should work just fine; only the db-scripts will really fail because they
>> cannot guess the svn-dir just from the package name anymore.
>
> Hmmm, this one I will have to think about. The devtools changes should
> be straightforward, but the db-scripts changes will not. Any ideas as
> to how we can convert a packagename to an svn-dir name? I'd rather not
> scan the whole repo...
Best I can do after some initial hacking. Are there any assumptions we
can make based on package name to trim the list so we don't have to
check all PKGBUILDs?
This is done without a checkout of the full repo, using svn list and svn cat...
$ ./pkgfind 3ddesktop #first package in the repos
Repo scan complete in 51ms
Package -> 3ddesktop/
$ ./pkgfind libpano13 #median package in the repos
Repo scan complete in 44170ms
Package -> libpano13/
$ ./pkgfind zsync #2nd to last package in the repos
Repo scan complete in 90997ms
Package -> zsync/
These numbers are just going to grow...
01-23-2009, 12:41 AM
Aaron Griffin
Divide and Konquer - Splitting KDE packages
On Thu, Jan 22, 2009 at 7:35 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
> On Thu, Jan 22, 2009 at 7:00 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
>> On Thu, Jan 22, 2009 at 6:21 PM, Pierre Schmitz <pierre@archlinux.de> wrote:
>>> In addition to this we'll need to update our devtools and db-scripts to handle
>>> those packages right. extrapkg should be quite simple; archrelease and repo-
>>> add should work just fine; only the db-scripts will really fail because they
>>> cannot guess the svn-dir just from the package name anymore.
>>
>> Hmmm, this one I will have to think about. The devtools changes should
>> be straightforward, but the db-scripts changes will not. Any ideas as
>> to how we can convert a packagename to an svn-dir name? I'd rather not
>> scan the whole repo...
>
> Best I can do after some initial hacking. Are there any assumptions we
> can make based on package name to trim the list so we don't have to
> check all PKGBUILDs?
>
> This is done without a checkout of the full repo, using svn list and svn cat...
>
> $ ./pkgfind 3ddesktop #first package in the repos
> Repo scan complete in 51ms
> Package -> 3ddesktop/
>
> $ ./pkgfind bash
> Repo scan complete in 3809ms
> Package -> bash/
>
> $ ./pkgfind libpano13 #median package in the repos
> Repo scan complete in 44170ms
> Package -> libpano13/
>
> $ ./pkgfind zsync #2nd to last package in the repos
> Repo scan complete in 90997ms
> Package -> zsync/
>
> These numbers are just going to grow...
>
Optimization: If we assume the first letters match...
On Thu, Jan 22, 2009 at 7:35 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Thu, Jan 22, 2009 at 7:00 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Thu, Jan 22, 2009 at 6:21 PM, Pierre Schmitz <pierre@archlinux.de> wrote:
In addition to this we'll need to update our devtools and db-scripts to handle
those packages right. extrapkg should be quite simple; archrelease and repo-
add should work just fine; only the db-scripts will really fail because they
cannot guess the svn-dir just from the package name anymore.
Hmmm, this one I will have to think about. The devtools changes should
be straightforward, but the db-scripts changes will not. Any ideas as
to how we can convert a packagename to an svn-dir name? I'd rather not
scan the whole repo...
Best I can do after some initial hacking. Are there any assumptions we
can make based on package name to trim the list so we don't have to
check all PKGBUILDs?
This is done without a checkout of the full repo, using svn list and svn cat...
$ ./pkgfind 3ddesktop #first package in the repos
Repo scan complete in 51ms
Package -> 3ddesktop/
Thomas suggested using symlinks in the svn directory?
From his email: e.g.
mysql/trunk
mysql/repos/mysql/extra-{i686,x86_64}
mysql/repos/mysql-clients/extra-{i686,x86_64}
mysql/repos/mysql-libs/extra-{i686,x86_64}
mysql-clients -> mysql
mysql-libs -> mysql
That should solve most of the trouble here.
Allan
01-23-2009, 01:03 AM
Allan McRae
Divide and Konquer - Splitting KDE packages
Allan McRae wrote:
Aaron Griffin wrote:
On Thu, Jan 22, 2009 at 7:35 PM, Aaron Griffin
<aaronmgriffin@gmail.com> wrote:
On Thu, Jan 22, 2009 at 7:00 PM, Aaron Griffin
<aaronmgriffin@gmail.com> wrote:
On Thu, Jan 22, 2009 at 6:21 PM, Pierre Schmitz
<pierre@archlinux.de> wrote:
In addition to this we'll need to update our devtools and
db-scripts to handle
those packages right. extrapkg should be quite simple; archrelease
and repo-
add should work just fine; only the db-scripts will really fail
because they
cannot guess the svn-dir just from the package name anymore.
Hmmm, this one I will have to think about. The devtools changes should
be straightforward, but the db-scripts changes will not. Any ideas as
to how we can convert a packagename to an svn-dir name? I'd rather not
scan the whole repo...
Best I can do after some initial hacking. Are there any assumptions we
can make based on package name to trim the list so we don't have to
check all PKGBUILDs?
This is done without a checkout of the full repo, using svn list and
svn cat...
$ ./pkgfind 3ddesktop #first package in the repos
Repo scan complete in 51ms
Package -> 3ddesktop/
Thomas suggested using symlinks in the svn directory?
From his email: e.g. mysql/trunk
mysql/repos/mysql/extra-{i686,x86_64}
mysql/repos/mysql-clients/extra-{i686,x86_64}
mysql/repos/mysql-libs/extra-{i686,x86_64}
mysql-clients -> mysql
mysql-libs -> mysql
That should solve most of the trouble here.
I suppose I should clarify how I thought this would work. The extrapkg
etc. scripts just loop over ${pkgname[*]}, and commit it to the "main"
directory, being whatever the package puts it in. The packager would
need to make the symlinks for their other packages, much like we
currently have to set up pkgname/{trunk,repo} for any new package. Then
there should not need to be any changes in the db-scripts (I think...).
Allan
01-23-2009, 01:34 AM
Aaron Griffin
Divide and Konquer - Splitting KDE packages
On Thu, Jan 22, 2009 at 8:03 PM, Allan McRae <allan@archlinux.org> wrote:
> Allan McRae wrote:
>>
>> Aaron Griffin wrote:
>>>
>>> On Thu, Jan 22, 2009 at 7:35 PM, Aaron Griffin <aaronmgriffin@gmail.com>
>>> wrote:
>>>
>>>>
>>>> On Thu, Jan 22, 2009 at 7:00 PM, Aaron Griffin <aaronmgriffin@gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>> On Thu, Jan 22, 2009 at 6:21 PM, Pierre Schmitz <pierre@archlinux.de>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> In addition to this we'll need to update our devtools and db-scripts
>>>>>> to handle
>>>>>> those packages right. extrapkg should be quite simple; archrelease and
>>>>>> repo-
>>>>>> add should work just fine; only the db-scripts will really fail
>>>>>> because they
>>>>>> cannot guess the svn-dir just from the package name anymore.
>>>>>>
>>>>>
>>>>> Hmmm, this one I will have to think about. The devtools changes should
>>>>> be straightforward, but the db-scripts changes will not. Any ideas as
>>>>> to how we can convert a packagename to an svn-dir name? I'd rather not
>>>>> scan the whole repo...
>>>>>
>>>>
>>>> Best I can do after some initial hacking. Are there any assumptions we
>>>> can make based on package name to trim the list so we don't have to
>>>> check all PKGBUILDs?
>>>>
>>>> This is done without a checkout of the full repo, using svn list and svn
>>>> cat...
>>>>
>>>> $ ./pkgfind 3ddesktop #first package in the repos
>>>> Repo scan complete in 51ms
>>>> Package -> 3ddesktop/
>>>>
>>>> $ ./pkgfind bash
>>>> Repo scan complete in 3809ms
>>>> Package -> bash/
>>>>
>>>> $ ./pkgfind libpano13 #median package in the repos
>>>> Repo scan complete in 44170ms
>>>> Package -> libpano13/
>>>>
>>>> $ ./pkgfind zsync #2nd to last package in the repos
>>>> Repo scan complete in 90997ms
>>>> Package -> zsync/
>>>>
>>>> These numbers are just going to grow...
>>>>
>>>>
>>>
>>> Optimization: If we assume the first letters match...
>>>
>>> $ ./pkgfind libpano13
>>> Repo scan complete in 5555ms
>>> Package -> libpano13/
>>>
>>> $ ./pkgfind zvbi
>>> Repo scan complete in 599ms
>>> Package -> zvbi/
>>>
>>> $ ./pkgfind zsync
>>> Repo scan complete in 539ms
>>> Package -> zsync/
>>>
>>> $ ./pkgfind yasm
>>> Repo scan complete in 235ms
>>> Package -> yasm/
>>>
>>> $ ./pkgfind perlxml
>>> Repo scan complete in 3473ms
>>> Package -> perlxml/
>>>
>>
>> Thomas suggested using symlinks in the svn directory?
>> From his email: e.g. mysql/trunk
>> mysql/repos/mysql/extra-{i686,x86_64}
>> mysql/repos/mysql-clients/extra-{i686,x86_64}
>> mysql/repos/mysql-libs/extra-{i686,x86_64}
>> mysql-clients -> mysql
>> mysql-libs -> mysql
>>
>> That should solve most of the trouble here.
>>
>
> I suppose I should clarify how I thought this would work. The extrapkg
> etc. scripts just loop over ${pkgname[*]}, and commit it to the "main"
> directory, being whatever the package puts it in. The packager would need
> to make the symlinks for their other packages, much like we currently have
> to set up pkgname/{trunk,repo} for any new package. Then there should not
> need to be any changes in the db-scripts (I think...).
Yes, the db-scripts are the complication.
For a given package, foo, the db-scripts check for
svn-packages/foot/repos/$REPO-$ARCH to ensure that the package should
be in this repo and that the version in svn is the same as the
package.
Because we can have svn-packages/foo/trunk/PKGBUILD build a package
named bar, the above isn't as simple as it once was. We NOW need to
scan through all PKGBUILDs when we look for the proper version for a
package named "bar"
01-23-2009, 01:51 AM
Allan McRae
Divide and Konquer - Splitting KDE packages
Aaron Griffin wrote:
On Thu, Jan 22, 2009 at 8:03 PM, Allan McRae <allan@archlinux.org> wrote:
Allan McRae wrote:
Aaron Griffin wrote:
On Thu, Jan 22, 2009 at 7:35 PM, Aaron Griffin <aaronmgriffin@gmail.com>
wrote:
On Thu, Jan 22, 2009 at 7:00 PM, Aaron Griffin <aaronmgriffin@gmail.com>
wrote:
On Thu, Jan 22, 2009 at 6:21 PM, Pierre Schmitz <pierre@archlinux.de>
wrote:
In addition to this we'll need to update our devtools and db-scripts
to handle
those packages right. extrapkg should be quite simple; archrelease and
repo-
add should work just fine; only the db-scripts will really fail
because they
cannot guess the svn-dir just from the package name anymore.
Hmmm, this one I will have to think about. The devtools changes should
be straightforward, but the db-scripts changes will not. Any ideas as
to how we can convert a packagename to an svn-dir name? I'd rather not
scan the whole repo...
Best I can do after some initial hacking. Are there any assumptions we
can make based on package name to trim the list so we don't have to
check all PKGBUILDs?
This is done without a checkout of the full repo, using svn list and svn
cat...
$ ./pkgfind 3ddesktop #first package in the repos
Repo scan complete in 51ms
Package -> 3ddesktop/
Thomas suggested using symlinks in the svn directory?
From his email: e.g. mysql/trunk
mysql/repos/mysql/extra-{i686,x86_64}
mysql/repos/mysql-clients/extra-{i686,x86_64}
mysql/repos/mysql-libs/extra-{i686,x86_64}
mysql-clients -> mysql
mysql-libs -> mysql
That should solve most of the trouble here.
I suppose I should clarify how I thought this would work. The extrapkg
etc. scripts just loop over ${pkgname[*]}, and commit it to the "main"
directory, being whatever the package puts it in. The packager would need
to make the symlinks for their other packages, much like we currently have
to set up pkgname/{trunk,repo} for any new package. Then there should not
need to be any changes in the db-scripts (I think...).
Yes, the db-scripts are the complication.
For a given package, foo, the db-scripts check for
svn-packages/foot/repos/$REPO-$ARCH to ensure that the package should
be in this repo and that the version in svn is the same as the
package.
Because we can have svn-packages/foo/trunk/PKGBUILD build a package
named bar, the above isn't as simple as it once was. We NOW need to
scan through all PKGBUILDs when we look for the proper version for a
package named "bar"
I am missing something here. Why can't it just check for
svn-packages/bar/repos/$REPO-$ARCH once the symlinks are added in svn?
Maybe have extrapkg check that the symlinks are created and do it
automatically if not.
Allan
01-23-2009, 01:58 AM
Aaron Griffin
Divide and Konquer - Splitting KDE packages
On Thu, Jan 22, 2009 at 8:51 PM, Allan McRae <allan@archlinux.org> wrote:
> Aaron Griffin wrote:
>>
>> On Thu, Jan 22, 2009 at 8:03 PM, Allan McRae <allan@archlinux.org> wrote:
>>
>>>
>>> Allan McRae wrote:
>>>
>>>>
>>>> Aaron Griffin wrote:
>>>>
>>>>>
>>>>> On Thu, Jan 22, 2009 at 7:35 PM, Aaron Griffin
>>>>> <aaronmgriffin@gmail.com>
>>>>> wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> On Thu, Jan 22, 2009 at 7:00 PM, Aaron Griffin
>>>>>> <aaronmgriffin@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On Thu, Jan 22, 2009 at 6:21 PM, Pierre Schmitz <pierre@archlinux.de>
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> In addition to this we'll need to update our devtools and db-scripts
>>>>>>>> to handle
>>>>>>>> those packages right. extrapkg should be quite simple; archrelease
>>>>>>>> and
>>>>>>>> repo-
>>>>>>>> add should work just fine; only the db-scripts will really fail
>>>>>>>> because they
>>>>>>>> cannot guess the svn-dir just from the package name anymore.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Hmmm, this one I will have to think about. The devtools changes
>>>>>>> should
>>>>>>> be straightforward, but the db-scripts changes will not. Any ideas as
>>>>>>> to how we can convert a packagename to an svn-dir name? I'd rather
>>>>>>> not
>>>>>>> scan the whole repo...
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Best I can do after some initial hacking. Are there any assumptions we
>>>>>> can make based on package name to trim the list so we don't have to
>>>>>> check all PKGBUILDs?
>>>>>>
>>>>>> This is done without a checkout of the full repo, using svn list and
>>>>>> svn
>>>>>> cat...
>>>>>>
>>>>>> $ ./pkgfind 3ddesktop #first package in the repos
>>>>>> Repo scan complete in 51ms
>>>>>> Package -> 3ddesktop/
>>>>>>
>>>>>> $ ./pkgfind bash
>>>>>> Repo scan complete in 3809ms
>>>>>> Package -> bash/
>>>>>>
>>>>>> $ ./pkgfind libpano13 #median package in the repos
>>>>>> Repo scan complete in 44170ms
>>>>>> Package -> libpano13/
>>>>>>
>>>>>> $ ./pkgfind zsync #2nd to last package in the repos
>>>>>> Repo scan complete in 90997ms
>>>>>> Package -> zsync/
>>>>>>
>>>>>> These numbers are just going to grow...
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> Optimization: If we assume the first letters match...
>>>>>
>>>>> $ ./pkgfind libpano13
>>>>> Repo scan complete in 5555ms
>>>>> Package -> libpano13/
>>>>>
>>>>> $ ./pkgfind zvbi
>>>>> Repo scan complete in 599ms
>>>>> Package -> zvbi/
>>>>>
>>>>> $ ./pkgfind zsync
>>>>> Repo scan complete in 539ms
>>>>> Package -> zsync/
>>>>>
>>>>> $ ./pkgfind yasm
>>>>> Repo scan complete in 235ms
>>>>> Package -> yasm/
>>>>>
>>>>> $ ./pkgfind perlxml
>>>>> Repo scan complete in 3473ms
>>>>> Package -> perlxml/
>>>>>
>>>>>
>>>>
>>>> Thomas suggested using symlinks in the svn directory?
>>>> From his email: e.g. mysql/trunk
>>>> mysql/repos/mysql/extra-{i686,x86_64}
>>>> mysql/repos/mysql-clients/extra-{i686,x86_64}
>>>> mysql/repos/mysql-libs/extra-{i686,x86_64}
>>>> mysql-clients -> mysql
>>>> mysql-libs -> mysql
>>>>
>>>> That should solve most of the trouble here.
>>>>
>>>>
>>>
>>> I suppose I should clarify how I thought this would work. The extrapkg
>>> etc. scripts just loop over ${pkgname[*]}, and commit it to the "main"
>>> directory, being whatever the package puts it in. The packager would
>>> need
>>> to make the symlinks for their other packages, much like we currently
>>> have
>>> to set up pkgname/{trunk,repo} for any new package. Then there should
>>> not
>>> need to be any changes in the db-scripts (I think...).
>>>
>>
>> Yes, the db-scripts are the complication.
>>
>> For a given package, foo, the db-scripts check for
>> svn-packages/foot/repos/$REPO-$ARCH to ensure that the package should
>> be in this repo and that the version in svn is the same as the
>> package.
>>
>> Because we can have svn-packages/foo/trunk/PKGBUILD build a package
>> named bar, the above isn't as simple as it once was. We NOW need to
>> scan through all PKGBUILDs when we look for the proper version for a
>> package named "bar"
>>
>
> I am missing something here. Why can't it just check for
> svn-packages/bar/repos/$REPO-$ARCH once the symlinks are added in svn?
> Maybe have extrapkg check that the symlinks are created and do it
> automatically if not.
Oh no, *I* missed it... the symlinks are top level. I get it now.
01-23-2009, 02:05 AM
Allan McRae
Divide and Konquer - Splitting KDE packages
Aaron Griffin wrote:
On Thu, Jan 22, 2009 at 8:51 PM, Allan McRae <allan@archlinux.org> wrote:
Aaron Griffin wrote:
On Thu, Jan 22, 2009 at 8:03 PM, Allan McRae <allan@archlinux.org> wrote:
Allan McRae wrote:
Aaron Griffin wrote:
On Thu, Jan 22, 2009 at 7:35 PM, Aaron Griffin
<aaronmgriffin@gmail.com>
wrote:
On Thu, Jan 22, 2009 at 7:00 PM, Aaron Griffin
<aaronmgriffin@gmail.com>
wrote:
On Thu, Jan 22, 2009 at 6:21 PM, Pierre Schmitz <pierre@archlinux.de>
wrote:
In addition to this we'll need to update our devtools and db-scripts
to handle
those packages right. extrapkg should be quite simple; archrelease
and
repo-
add should work just fine; only the db-scripts will really fail
because they
cannot guess the svn-dir just from the package name anymore.
Hmmm, this one I will have to think about. The devtools changes
should
be straightforward, but the db-scripts changes will not. Any ideas as
to how we can convert a packagename to an svn-dir name? I'd rather
not
scan the whole repo...
Best I can do after some initial hacking. Are there any assumptions we
can make based on package name to trim the list so we don't have to
check all PKGBUILDs?
This is done without a checkout of the full repo, using svn list and
svn
cat...
$ ./pkgfind 3ddesktop #first package in the repos
Repo scan complete in 51ms
Package -> 3ddesktop/
Thomas suggested using symlinks in the svn directory?
From his email: e.g. mysql/trunk
mysql/repos/mysql/extra-{i686,x86_64}
mysql/repos/mysql-clients/extra-{i686,x86_64}
mysql/repos/mysql-libs/extra-{i686,x86_64}
mysql-clients -> mysql
mysql-libs -> mysql
That should solve most of the trouble here.
I suppose I should clarify how I thought this would work. The extrapkg
etc. scripts just loop over ${pkgname[*]}, and commit it to the "main"
directory, being whatever the package puts it in. The packager would
need
to make the symlinks for their other packages, much like we currently
have
to set up pkgname/{trunk,repo} for any new package. Then there should
not
need to be any changes in the db-scripts (I think...).
Yes, the db-scripts are the complication.
For a given package, foo, the db-scripts check for
svn-packages/foot/repos/$REPO-$ARCH to ensure that the package should
be in this repo and that the version in svn is the same as the
package.
Because we can have svn-packages/foo/trunk/PKGBUILD build a package
named bar, the above isn't as simple as it once was. We NOW need to
scan through all PKGBUILDs when we look for the proper version for a
package named "bar"
I am missing something here. Why can't it just check for
svn-packages/bar/repos/$REPO-$ARCH once the symlinks are added in svn?
Maybe have extrapkg check that the symlinks are created and do it
automatically if not.
Oh no, *I* missed it... the symlinks are top level. I get it now.
That could be because of the example I cut from Thomas' email. The extra
folder level in the repos directory is unneed because the PKGBUILD and
source are the same for all the split packages. It should be like:
mysql/repos/extra-{i686,x86_64}
mysql-clients -> mysql
mysql-libs -> mysql