[arch-dev-public] 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
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
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...
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/
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
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
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"
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
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.
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
participants (3)
-
Aaron Griffin
-
Allan McRae
-
Pierre Schmitz