FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Development

 
 
LinkBack Thread Tools
 
Old 01-22-2009, 11:21 PM
Pierre Schmitz
 
Default Divide and Konquer - Splitting KDE packages

Hey guys,

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>

pkgname=('filesharing'
'kdnssd'
'kget'
'kopete'
'krdc'
'krfb')
pkgver=4.1.96
pkgrel=1
arch=('i686' 'x86_64')
url='http://www.kde.org'
license=('GPL' 'LGPL' 'FDL')
groups=('kde' 'kdenetwork')
makedepends=('pkgconfig' 'cmake' 'automoc4' 'boost' 'kdebase-workspace' 'libvncserver' 'libidn' 'libotr' 'qca' 'libmsn' 'ortp')
options=('docs')
source=("http://download.kde.org/unstable/${pkgver}/src/kdenetwork-${pkgver}.tar.bz2")
md5sums=('01c69a5982758b4939627a6c4aa8fd55')

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
}
 
Old 01-23-2009, 12:00 AM
Aaron Griffin
 
Default 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
 
Old 01-23-2009, 12:35 AM
Aaron Griffin
 
Default 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 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...
 
Old 01-23-2009, 12:41 AM
Aaron Griffin
 
Default 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...

$ ./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/
 
Old 01-23-2009, 12:59 AM
Allan McRae
 
Default Divide and Konquer - Splitting KDE packages

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.

Allan
 
Old 01-23-2009, 01:03 AM
Allan McRae
 
Default 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/

$ ./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...).


Allan
 
Old 01-23-2009, 01:34 AM
Aaron Griffin
 
Default 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"
 
Old 01-23-2009, 01:51 AM
Allan McRae
 
Default 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/

$ ./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.


Allan
 
Old 01-23-2009, 01:58 AM
Aaron Griffin
 
Default 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.
 
Old 01-23-2009, 02:05 AM
Allan McRae
 
Default 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/

$ ./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.



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

Allan
 

Thread Tools




All times are GMT. The time now is 08:49 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org