Hi there, Lately, I've been going through the TODO list of prt-get, and started to implement some of them; cause they're changing the user experience quite drastically, I'd like to hear what people think about them. Since both the old and the new variant rely on the same core, it should be fairly easy to keep around both if we want to. So if you don't like what you read, don't worry :-). There are two major chances: 1. User interface: less commands -------------------------------- Many of its current features weren't there from the start, and I've usually chosen to add a separate 'command' (think: prt-get <command> ...), for example depends/deptree/dependent. In addition, there's a major overlap between some of the commands in query (printf is just a more specific form of either list or info, depending on the filter argument). For a long time, I wanted to change this, and finally got around it. That might look like this: [old] [new] prt-get depends <port> pgt depends <port> prt-get deptree <port> pgt depends -T <port> prt-get quickdep <port> pgt depends -Q <port> prt-get dependent <port> pgt depends -R <port> (reverse) prt-get diff [<port>] pgt diff [<port>] prt-get quickdiff [<port>] pgt diff -Q [<port>] Note how -Q has the same meaning. There a list of mapping here: http://jw.smts.ch/pg-ng 7 commands in pgt replace 18 in prt-get. The 'find' generalizations might be a bit too much, I may go for a find/list combo. 2. Dependency handling ---------------------- When prt-get was introduced, the "Depends on:" header was optional (and somtimes even frowned upon). As a consequence of this, the default 'install' command did not install dependencies. As a side effect, 'update' and 'sysup' never got --with-deps options, since it's impossible to tell whether a user omitted a dependency by calling 'install' instead of 'depinst' or whether it was introduced in the last update (think: pkgutils and libarchive). Nowadays, things are different: we expect people to install dependencies, and if errors get reported we typically ask first whether all dependencies are met. Therefore, I'd suggest the following: - pgt install <port> would install <port> and its dependencies (like depinst) - pgt update <port> would install <port>'s missing dependencies, and update <port> - pgt sysup would install all missing dependencies, and update outdated ports in the system All commands will get a -N/--no-deps switch to really only handle a single port, however the next update or sysup will of course bring them back. In other words prt-get no more silently assumes that the user didn't want a particular dependency. Now, if you don't want a package (and believe it's only an optional dependency for your usage pattern although the maintainer listed it), you can still do it, but explicitely by calling 'pgt lock' on an uninstalled package. Locked packages won't be touched by any pgt command (but there will be a warning printed in the end of install if a locked dependency was requested in that transaction). As mentioned, I'd like to hear your comments on those two changes. I'm sure both will take some time to get used to (heck, even the new name; I keep typing 'prt-get' on the machine where I installed pgt to test it ;-)), but are worth it in the long run. Best regards, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
On Wed, 18 Jun 2008 08:15:37 +0200 Johannes Winkelmann <jw@smts.ch> wrote:
Hi there,
Hey Johannes,
Lately, I've been going through the TODO list of prt-get, and started to implement some of them; cause they're changing the user experience quite drastically, I'd like to hear what people think about them. Since both the old and the new variant rely on the same core, it should be fairly easy to keep around both if we want to. So if you don't like what you read, don't worry :-).
let's see.
There are two major chances:
1. User interface: less commands --------------------------------
Many of its current features weren't there from the start, and I've usually chosen to add a separate 'command' (think: prt-get <command> ...), for example depends/deptree/dependent. In addition, there's a major overlap between some of the commands in query (printf is just a more specific form of either list or info, depending on the filter argument). For a long time, I wanted to change this, and finally got around it. That might look like this:
[old] [new] prt-get depends <port> pgt depends <port> prt-get deptree <port> pgt depends -T <port> prt-get quickdep <port> pgt depends -Q <port> prt-get dependent <port> pgt depends -R <port> (reverse)
prt-get diff [<port>] pgt diff [<port>] prt-get quickdiff [<port>] pgt diff -Q [<port>]
Note how -Q has the same meaning. There a list of mapping here: http://jw.smts.ch/pg-ng 7 commands in pgt replace 18 in prt-get. The 'find' generalizations might be a bit too much, I may go for a find/list combo.
I see less commands but less intuitive too. May be with its use, it will be more intuitive (like all things).
2. Dependency handling ---------------------- When prt-get was introduced, the "Depends on:" header was optional (and somtimes even frowned upon). As a consequence of this, the default 'install' command did not install dependencies. As a side effect, 'update' and 'sysup' never got --with-deps options, since it's impossible to tell whether a user omitted a dependency by calling 'install' instead of 'depinst' or whether it was introduced in the last update (think: pkgutils and libarchive).
Nowadays, things are different: we expect people to install dependencies, and if errors get reported we typically ask first whether all dependencies are met. Therefore, I'd suggest the following:
- pgt install <port> would install <port> and its dependencies (like depinst) - pgt update <port> would install <port>'s missing dependencies, and update <port> - pgt sysup would install all missing dependencies, and update outdated ports in the system
All commands will get a -N/--no-deps switch to really only handle a single port, however the next update or sysup will of course bring them back.
In other words prt-get no more silently assumes that the user didn't want a particular dependency.
In this way, you remove the diy though by default. I mean, you make things automated instead of let the user keep track of ports/packages. This sure will avoid some errors (using install instead of depinst and automated keep track of new dependencies of ports when you make a sysup).
Now, if you don't want a package (and believe it's only an optional dependency for your usage pattern although the maintainer listed it), you can still do it, but explicitely by calling 'pgt lock' on an uninstalled package. Locked packages won't be touched by any pgt command (but there will be a warning printed in the end of install if a locked dependency was requested in that transaction).
If I understand it well, I think it's the same functionallity like we have now with prt-get (a locked port isn't touched) adding the new warning print and the fact of locking not installed ports too.
As mentioned, I'd like to hear your comments on those two changes. I'm sure both will take some time to get used to (heck, even the new name; I keep typing 'prt-get' on the machine where I installed pgt to test it ;-)), but are worth it in the long run.
I hope this comments can be usefull.
Best regards, Johannes Regards, Victor.
-- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
-- Learning bit by bit. -pitillo-
Hi Victor, On Wed, Jun 18, 2008 at 09:07:27 +0200, Victor Martinez wrote:
On Wed, 18 Jun 2008 08:15:37 +0200 Johannes Winkelmann <jw@smts.ch> wrote: [...]
1. User interface: less commands -------------------------------- [...] http://jw.smts.ch/pg-ng 7 commands in pgt replace 18 in prt-get. The 'find' generalizations might be a bit too much, I may go for a find/list combo.
I see less commands but less intuitive too. May be with its use, it will be more intuitive (like all things). Agreed, it'll definitely take some time to get used to it. I'll try to upload a test version as soon as possible, it's hard to get a real feeling without using it.
I'd also agree that after such a long time, it's maybe a bad idea to change the interface so drastically. OTOH I think just because we got used to something doesn't make it less ugly :-), which is reason enough to think about changing it.
2. Dependency handling ---------------------- [...] In this way, you remove the diy though by default. I mean, you make things automated instead of let the user keep track of ports/packages. Yes, the default behaviour is changing. I'm not sure how many users resolve dependencies by hand, that's one reason for this RFC.
I typically use 'install' myself, but I have to admit I don't know why. And if I don't want t dependency, I typically use --ignore= along with depinst. In this case, I could just as well use 'lock' to make it clear. I'd really like to hear how others handle this. Do you normally use install and track dependencies by hand? Do you often ignore dependencies as specified by the maintainer? Should "depinst/install -D" be optional, for example for large transaction like gnome? An alternative approach could be to make this user configurable, i.e. have 'install -D' (with dependencies) and 'install -N' (no dependencies), and let the user set the default behaviour if none is specified. Thanks for your comments, Regards Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
On Wed, 18 Jun 2008 10:24:49 +0200 Johannes Winkelmann <jw@smts.ch> wrote:
Hi Victor,
On Wed, Jun 18, 2008 at 09:07:27 +0200, Victor Martinez wrote:
On Wed, 18 Jun 2008 08:15:37 +0200 Johannes Winkelmann <jw@smts.ch> wrote: [...]
1. User interface: less commands -------------------------------- [...] http://jw.smts.ch/pg-ng 7 commands in pgt replace 18 in prt-get. The 'find' generalizations might be a bit too much, I may go for a find/list combo.
I see less commands but less intuitive too. May be with its use, it will be more intuitive (like all things). Agreed, it'll definitely take some time to get used to it. I'll try to upload a test version as soon as possible, it's hard to get a real feeling without using it.
The test version can be good for testing objectives too. (Bug tracking, new improvements, comments about the code...)
I'd also agree that after such a long time, it's maybe a bad idea to change the interface so drastically. OTOH I think just because we got used to something doesn't make it less ugly :-), which is reason enough to think about changing it.
Well, if the objective is to make things better, I can't see a problem to make those changes, using this new version will solve the problem with time ahead, the more use, the more confortable we will be with it. The only problem I can see is for someone who manages some workstations and uses personal scripts for maintain them, it can be a bit hard to adopt this new pgt over prt-get, but all can be changed/adopted to a new version with tests and patience.
2. Dependency handling ---------------------- [...] In this way, you remove the diy though by default. I mean, you make things automated instead of let the user keep track of ports/packages. Yes, the default behaviour is changing. I'm not sure how many users resolve dependencies by hand, that's one reason for this RFC.
I typically use 'install' myself, but I have to admit I don't know why. And if I don't want t dependency, I typically use --ignore= along with depinst. In this case, I could just as well use 'lock' to make it clear.
I'd really like to hear how others handle this. Do you normally use install and track dependencies by hand? Do you often ignore dependencies as specified by the maintainer? Should "depinst/install -D" be optional, for example for large transaction like gnome?
In my case I feel very confortable with the depinst command. I am using it over opt/contrib. I try to keep track of dependencies (deptree) and see if all are covered in those repos (which following the guidelines must cover this issue in contrib). For private repositories I try to check Pkgfiles and all deps, sometimes without using depinst, but if the private repo came from a trust user, I only check Pkgfiles to see if they follow the standard way to build Pkgfiles (some of them don't use --disable-nls for example). I hope people can check this thread and give comments about it, to see how they work and see if they can show issues/problems or any kind of comment, which will be usefull for the comunity.
An alternative approach could be to make this user configurable, i.e. have 'install -D' (with dependencies) and 'install -N' (no dependencies), and let the user set the default behaviour if none is specified.
I see the default policy using -D to keep track of all deps, I mean, to use the new advatanges about deps tracking (1 of the changes). Giving the user the config option (commented out by default for example) can be good too.
Thanks for your comments, Regards Johannes
Thank you too for your work and new improvements. -- Learning bit by bit. -pitillo-
On Wed, 18 Jun 2008 10:24:49 +0200 Johannes Winkelmann wrote:
I'd really like to hear how others handle this. Do you normally use install and track dependencies by hand? Do you often ignore dependencies as specified by the maintainer? Should "depinst/install -D" be optional, for example for large transaction like gnome?
If port is in core/opt, I use depinst, most of the time.If it's from contrib/private repo, yapo is the way to go for resolving deps, or I modify the port to suit my needs, and put it in my private repo.
An alternative approach could be to make this user configurable, i.e. have 'install -D' (with dependencies) and 'install -N' (no dependencies), and let the user set the default behaviour if none is specified.
I agree that this should be user configurable, but with 'install -D' set as default, because most of the time you want to install port with all of its dependencies.
Thanks for your comments,
Glad to see you back in business, Johannes :) I'm looking forward to testing this pgt thingie.
Regards Johannes
Pedja -- <Disko> I USE CAPS LOCK BECAUSE I WILL BECOME NOTICED, POPULAR, AND GOOD IN BED. - bash.org
Hello, Johannes. On Wed, 18 Jun 2008 10:24:49 +0200 Johannes Winkelmann <jw@smts.ch> wrote:
[...] I'd really like to hear how others handle this. Do you normally use install and track dependencies by hand? Do you often ignore dependencies as specified by the maintainer? Should "depinst/install -D" be optional, for example for large transaction like gnome?
An alternative approach could be to make this user configurable, i.e. have 'install -D' (with dependencies) and 'install -N' (no dependencies), and let the user set the default behaviour if none is specified.
If the default behavior (with default configuration file) would be to omit dependencies - it's is not much better than plain pkgmk/pkgadd. While I'd like that new 'install' command would act like the old 'depinst', it would definitely take some time to get used to it. A related topic is a single library for a set of functions for package database operations. It would be a nice feature for pkgutils/prt-get/pgt or any other related software written in C. Any plans on the future integration? -- Mikhail Kolesnik ICQ: 260259143 IRC: mike_k at freenode/#crux, rusnet/#yalta
Hi mike_k, On Wed, Jun 18, 2008 at 15:01:07 +0300, Mikhail Kolesnik wrote:
Hello, Johannes. [...] A related topic is a single library for a set of functions for package database operations. It would be a nice feature for pkgutils/prt-get/pgt or any other related software written in C. Any plans on the future integration?
Not at this point in time, mainly due to lack of time. I hope we can get there though, it would definitely be a nice thing to have. Thanks for your input, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
Johannes Winkelmann [2008-06-22 12:05]:
Hi mike_k,
On Wed, Jun 18, 2008 at 15:01:07 +0300, Mikhail Kolesnik wrote:
Hello, Johannes. [...] A related topic is a single library for a set of functions for package database operations. It would be a nice feature for pkgutils/prt-get/pgt or any other related software written in C. Any plans on the future integration?
Not at this point in time, mainly due to lack of time. I hope we can get there though, it would definitely be a nice thing to have.
That would be pkgutils6, btw. It's still lacking support for adding packages to the system though ;) Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
On Wed, 18 Jun 2008, Johannes Winkelmann wrote:
Hi Victor,
On Wed, Jun 18, 2008 at 09:07:27 +0200, Victor Martinez wrote:
On Wed, 18 Jun 2008 08:15:37 +0200 Johannes Winkelmann <jw@smts.ch> wrote: [...]
[...]
In this way, you remove the diy though by default. I mean, you make things automated instead of let the user keep track of ports/packages. Yes, the default behaviour is changing. I'm not sure how many users resolve dependencies by hand, that's one reason for this RFC.
Hi Johannes, nice to see you back. Just a point on this, I dont keep track, but I use Jue's Yapo. That way I see how many dependencies are involved at any stage and can decide whether to proceed or not. It is one thing that keeps me enjoying Crux; it would be a very different experience without it. regards, clare
Johannes Winkelmann [2008-06-18 10:24]:
On Wed, Jun 18, 2008 at 09:07:27 +0200, Victor Martinez wrote:
On Wed, 18 Jun 2008 08:15:37 +0200 Johannes Winkelmann <jw@smts.ch> wrote:
[snip]
2. Dependency handling ---------------------- [...] In this way, you remove the diy though by default. I mean, you make things automated instead of let the user keep track of ports/packages. Yes, the default behaviour is changing. I'm not sure how many users resolve dependencies by hand, that's one reason for this RFC.
I typically use 'install' myself, but I have to admit I don't know why. And if I don't want t dependency, I typically use --ignore= along with depinst. In this case, I could just as well use 'lock' to make it clear.
I'd really like to hear how others handle this. Do you normally use install and track dependencies by hand? Do you often ignore dependencies as specified by the maintainer? Should "depinst/install -D" be optional, for example for large transaction like gnome?
I paid attention to how I am using prt-get over the last few days. I seem to often use deptree on a package I'm about to install, to check that it doesn't pull in weird stuff that I don't like (yes, I'm silly). Afterwards I run prt-get install or prt-get depinst. I like what I've read here so far, though, and I think defaulting to depinst behaviour should be okay; I would just have to remember locking packages that I don't want :) Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
On Fri, Jun 20, 2008 at 08:32:39PM +0200, Tilman Sauerbeck wrote:
Johannes Winkelmann [2008-06-18 10:24]:
On Wed, Jun 18, 2008 at 09:07:27 +0200, Victor Martinez wrote:
On Wed, 18 Jun 2008 08:15:37 +0200 Johannes Winkelmann <jw@smts.ch> wrote:
[snip]
2. Dependency handling ---------------------- [...]
I paid attention to how I am using prt-get over the last few days. I seem to often use deptree on a package I'm about to install, to check that it doesn't pull in weird stuff that I don't like (yes, I'm silly). Afterwards I run prt-get install or prt-get depinst.
[...] I do the same, however with new xorg in modules it a bit more difficult. Wawrzek -- Wawrzyniec Niewodniczański (in some countries know as Larry) vel LarryN E-MAIL: wawrzyniec.niewodniczanski@pwr.wroc.pl PhD student @ JID: larryn@chrome.pl Wroclaw University of Technology TEL: +48(071)320-2894
Hi, Victor Martinez wrote:
On Wed, 18 Jun 2008 08:15:37 +0200 Johannes Winkelmann <jw@smts.ch> wrote:
There are two major chances:
1. User interface: less commands --------------------------------
Many of its current features weren't there from the start, and I've usually chosen to add a separate 'command' (think: prt-get <command> ...), for example depends/deptree/dependent. In addition, there's a major overlap between some of the commands in query (printf is just a more specific form of either list or info, depending on the filter argument). For a long time, I wanted to change this, and finally got around it. That might look like this:
[old] [new] prt-get depends <port> pgt depends <port> prt-get deptree <port> pgt depends -T <port> prt-get quickdep <port> pgt depends -Q <port> prt-get dependent <port> pgt depends -R <port> (reverse)
prt-get diff [<port>] pgt diff [<port>] prt-get quickdiff [<port>] pgt diff -Q [<port>]
Note how -Q has the same meaning. There a list of mapping here: http://jw.smts.ch/pg-ng In this list, the 'depends' subcommand is replaced and grouped by the 'dep' one, which sounds better for me. Other subcommands replacements as 'find' are fine too, but I have in my mind an alternative for 'sysup'. Both 'up' and 'sysup' subcommands could be grouped into the 'up' one, -N and -D options are shared and, as I known 'up' is a subset of 'sysup'. So for me sounds better:
prt-get up prt-get update <options> package prt-get sysup prt-get update -a (means try to update all packages installed) You're mixing upper with lowercase options, (e.g: pgt diff -Q, pgt find -f) and IMO they should be in lowercase. Also, there are a number of subcommands still without alternatives in your list, like: path, dup, listorphans, dumpconfig, cache, ...
2. Dependency handling ---------------------- When prt-get was introduced, the "Depends on:" header was optional (and somtimes even frowned upon). As a consequence of this, the default 'install' command did not install dependencies. As a side effect, 'update' and 'sysup' never got --with-deps options, since it's impossible to tell whether a user omitted a dependency by calling 'install' instead of 'depinst' or whether it was introduced in the last update (think: pkgutils and libarchive).
Nowadays, things are different: we expect people to install dependencies, and if errors get reported we typically ask first whether all dependencies are met. Therefore, I'd suggest the following:
- pgt install <port> would install <port> and its dependencies (like depinst) - pgt update <port> would install <port>'s missing dependencies, and update <port> - pgt sysup would install all missing dependencies, and update outdated ports in the system
All commands will get a -N/--no-deps switch to really only handle a single port, however the next update or sysup will of course bring them back.
In other words prt-get no more silently assumes that the user didn't want a particular dependency. In this way, you remove the diy though by default. I mean, you make things automated instead of let the user keep track of ports/packages. This sure will avoid some errors (using install instead of depinst and automated keep track of new dependencies of ports when you make a sysup). Maybe this switch can be added to prt-get.conf for anyone who keep track manually his ports. Now, if you don't want a package (and believe it's only an optional dependency for your usage pattern although the maintainer listed it), 'optional dependency' ?? :-) IMO. maintainers only should list necessary deps, and the rest ones should be listed as # Optional: But this is another point for discussions. you can still do it, but explicitely by calling 'pgt lock' on an uninstalled package. Locked packages won't be touched by any pgt command (but there will be a warning printed in the end of install if a locked dependency was requested in that transaction).
If I understand it well, I think it's the same functionallity like we have now with prt-get (a locked port isn't touched) adding the new warning print and the fact of locking not installed ports too.
Seems that now you can lock some deps listed by the Maintainer for building the port, so the lock switch should be accompanied by 'ignore footprint' or something similar (the built package surely differs from the original one). Just it keeps the DIY feature.
As mentioned, I'd like to hear your comments on those two changes. I'm sure both will take some time to get used to (heck, even the new name; I keep typing 'prt-get' on the machine where I installed pgt to test it ;-)), but are worth it in the long run.
Personally I don't like the idea of changing the 'prt-get' name. Well, I'm waiting a release candidate or beta for testing it.
Best regards, Jose V Beneyto
Hi Jose, On Wed, Jun 18, 2008 at 11:22:35 +0200, Jose V Beneyto wrote:
Hi,
Victor Martinez wrote:
On Wed, 18 Jun 2008 08:15:37 +0200 Johannes Winkelmann <jw@smts.ch> wrote:
There are two major chances:
1. User interface: less commands -------------------------------- [...] http://jw.smts.ch/pg-ng In this list, the 'depends' subcommand is replaced and grouped by the 'dep' one, which sounds better for me. Other subcommands replacements as 'find' are fine too, but I have in my mind an alternative for 'sysup'. Both 'up' and 'sysup' subcommands could be grouped into the 'up' one, -N and -D options are shared and, as I known 'up' is a subset of 'sysup'. So for me sounds better:
prt-get up prt-get update <options> package prt-get sysup prt-get update -a (means try to update all packages installed)
You're mixing upper with lowercase options, (e.g: pgt diff -Q, pgt find -f) and IMO they should be in lowercase. My idea was to have the global options (those used in multiple commands) uppercase, and those that are command specific lowercase. Not sure if
Yeah, that makes sense. I was thinking to give --all for update a different meaning, such that 'update <port> --all' would a) install missing dependencies b) update outdated dependencies that are already installed c) update <port> In other words, it would bring just one subtree up to date. At this point in time, I'm not sure if this is a good idea, or commonly used case. Regarding sysup, how about 'pgt update --system' (and 'pgt up --system')? that's a good idea though. Also, it's not used consistently (-R for reverse dependencies should be lowercase).
Also, there are a number of subcommands still without alternatives in your list, like: path, dup, listorphans, dumpconfig, cache, ... True;
- I like 'path' a fair bit, but it could also become 'info <port> --format=%p'. - listorphans should become 'list --orphans' - cache and dumpconfig can probably stay as is (the configuration file implementation will see some changes anyway). I'll write an updated mapping once I've collected all the feedback
Personally I don't like the idea of changing the 'prt-get' name. Well, at this point in time it's mainly for practical reasons, i.e. to allow using both at the same time. That said, I've found the short name (without the dash) nice to type.
Thanks for your comments, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
On Wed, 18 Jun 2008 08:15:37 +0200 Johannes Winkelmann <jw@smts.ch> wrote:
Hi there,
Lately, I've been going through the TODO list of prt-get, and started to implement some of them; cause they're changing the user experience quite drastically, I'd like to hear what people think about them. Since both the old and the new variant rely on the same core, it should be fairly easy to keep around both if we want to. So if you don't like what you read, don't worry :-).
What are the chances of getting concurrent downloads? *nudge nudge* -- Lucas Hazel <lucas@die.net.au>
On Wed, Jun 18, 2008 at 23:50:22 +1000, Lucas Hazel wrote:
On Wed, 18 Jun 2008 08:15:37 +0200 Johannes Winkelmann <jw@smts.ch> wrote:
Hi there,
Lately, I've been going through the TODO list of prt-get, and started to implement some of them; cause they're changing the user experience quite drastically, I'd like to hear what people think about them. Since both the old and the new variant rely on the same core, it should be fairly easy to keep around both if we want to. So if you don't like what you read, don't worry :-).
What are the chances of getting concurrent downloads? *nudge nudge*
I was actually planning to do just easy interface work, and pass it off as major improvement :-). Would be nice to have, I'll move that up when going through the TODO list. Thanks for the reminder :-). Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
participants (10)
-
Clare -
fikin -
Johannes Winkelmann -
Jose V Beneyto -
Lucas Hazel -
Mikhail Kolesnik -
Predrag Ivanovic -
Tilman Sauerbeck -
Victor Martinez -
Wawrzyniec Niewodniczański