[aur-general] Replacing nexuiz with xonotic
I'd like to see nexuiz replaced by xonotic in [community]. Problem is that nexuiz is still a fairly popular package despite being dead upstream. xonotic devs recommend dropping nexuiz in favor of xonotic. Technically, xonotic does not replace nexuiz because its gameplay is somewhat different. I'd like some opinions on this.
On Fri, 21 Oct 2011 02:50:31 +0200 Sven-Hendrik Haase <sh@lutzhaase.com> wrote:
I'd like to see nexuiz replaced by xonotic in [community]. Problem is that nexuiz is still a fairly popular package despite being dead upstream. xonotic devs recommend dropping nexuiz in favor of xonotic. Technically, xonotic does not replace nexuiz because its gameplay is somewhat different.
I'd like some opinions on this.
hi, imho: different game -> additional package nexuiz still popular -> keep package as is. Dieter
[2011-10-21 08:45:46 +0200] Dieter Plaetinck:
On Fri, 21 Oct 2011 02:50:31 +0200 Sven-Hendrik Haase <sh@lutzhaase.com> wrote:
I'd like to see nexuiz replaced by xonotic in [community]. Problem is that nexuiz is still a fairly popular package despite being dead upstream. xonotic devs recommend dropping nexuiz in favor of xonotic. Technically, xonotic does not replace nexuiz because its gameplay is somewhat different.
I'd like some opinions on this.
hi, imho: different game -> additional package nexuiz still popular -> keep package as is.
My two cents: I'm of those who believe that we can't keep throwing 1GB packages in the repos like there's no tomorrow. So if nexuiz and xonotic are quite similar, it makes sense to only package one of them and save the extra gigabyte for a different game. -- Gaetan
On Fri, Oct 21, 2011 at 9:20 AM, Gaetan Bisson <bisson@archlinux.org> wrote:
[2011-10-21 08:45:46 +0200] Dieter Plaetinck:
On Fri, 21 Oct 2011 02:50:31 +0200 Sven-Hendrik Haase <sh@lutzhaase.com> wrote:
I'd like to see nexuiz replaced by xonotic in [community]. Problem is that nexuiz is still a fairly popular package despite being dead upstream. xonotic devs recommend dropping nexuiz in favor of xonotic. Technically, xonotic does not replace nexuiz because its gameplay is somewhat different.
I'd like some opinions on this.
hi, imho: different game -> additional package nexuiz still popular -> keep package as is.
My two cents: I'm of those who believe that we can't keep throwing 1GB packages in the repos like there's no tomorrow. So if nexuiz and xonotic are quite similar, it makes sense to only package one of them and save the extra gigabyte for a different game.
-- Gaetan
I think that's the wrong reason for choosing to keep only one of the two packages. If the sizes of the packages are problematic that's a different issue. That said, being nexuiz a dead project may be a good enough reason to remove it. If not for that I would keep them both.
On 10/21/2011 11:00 AM, Massimiliano Torromeo wrote:
On Fri, Oct 21, 2011 at 9:20 AM, Gaetan Bisson<bisson@archlinux.org> wrote:
[2011-10-21 08:45:46 +0200] Dieter Plaetinck:
On Fri, 21 Oct 2011 02:50:31 +0200 Sven-Hendrik Haase<sh@lutzhaase.com> wrote:
I'd like to see nexuiz replaced by xonotic in [community]. Problem is that nexuiz is still a fairly popular package despite being dead upstream. xonotic devs recommend dropping nexuiz in favor of xonotic. Technically, xonotic does not replace nexuiz because its gameplay is somewhat different.
I'd like some opinions on this.
hi, imho: different game -> additional package nexuiz still popular -> keep package as is.
My two cents: I'm of those who believe that we can't keep throwing 1GB packages in the repos like there's no tomorrow. So if nexuiz and xonotic are quite similar, it makes sense to only package one of them and save the extra gigabyte for a different game.
-- Gaetan
I think that's the wrong reason for choosing to keep only one of the two packages. If the sizes of the packages are problematic that's a different issue.
That said, being nexuiz a dead project may be a good enough reason to remove it. If not for that I would keep them both.
i say to remove all games :D -- Ionuț
How about adding a message in the Nexuiz install file that Xonotic is the one to use and then move it to unsupported. Warmest regards, Alexander Rødseth Arch Linux Trusted User xyproto on IRC, trontonic on AUR 21. okt.. 2011 10.05 "Ionut Biru" <ibiru@archlinux.org>: On 10/21/2011 11:00 AM, Massimiliano Torromeo wrote:
On Fri, Oct 21, 2011 at 9:20 AM, Gaetan Bis...
i say to remove all games :D -- Ionuț
2011/10/21 Ionut Biru <ibiru@archlinux.org>:
On 10/21/2011 11:00 AM, Massimiliano Torromeo wrote:
On Fri, Oct 21, 2011 at 9:20 AM, Gaetan Bisson<bisson@archlinux.org> wrote:
[2011-10-21 08:45:46 +0200] Dieter Plaetinck:
On Fri, 21 Oct 2011 02:50:31 +0200 Sven-Hendrik Haase<sh@lutzhaase.com> wrote:
I'd like to see nexuiz replaced by xonotic in [community]. Problem is that nexuiz is still a fairly popular package despite being dead upstream. xonotic devs recommend dropping nexuiz in favor of xonotic. Technically, xonotic does not replace nexuiz because its gameplay is somewhat different.
I'd like some opinions on this.
hi, imho: different game -> additional package nexuiz still popular -> keep package as is.
My two cents: I'm of those who believe that we can't keep throwing 1GB packages in the repos like there's no tomorrow. So if nexuiz and xonotic are quite similar, it makes sense to only package one of them and save the extra gigabyte for a different game.
-- Gaetan
I think that's the wrong reason for choosing to keep only one of the two packages. If the sizes of the packages are problematic that's a different issue.
That said, being nexuiz a dead project may be a good enough reason to remove it. If not for that I would keep them both.
i say to remove all games :D
+1000 oh yeah, no kidding here :)
-- Ionuț
-- Angel Velásquez angvp @ irc.freenode.net Arch Linux Developer / Trusted User Linux Counter: #359909 http://www.angvp.com
[2011-10-21 10:00:37 +0200] Massimiliano Torromeo:
If the sizes of the packages are problematic that's a different issue.
Okay. Suppose that issue isn't entirely theoretical. How do we solve it? -- Gaetan
On Fri, Oct 21, 2011 at 2:07 PM, Gaetan Bisson <bisson@archlinux.org> wrote:
[2011-10-21 10:00:37 +0200] Massimiliano Torromeo:
If the sizes of the packages are problematic that's a different issue.
Okay. Suppose that issue isn't entirely theoretical. How do we solve it?
-- Gaetan
Well, first we should define why it is an issue.
2011/10/21 Massimiliano Torromeo <massimiliano.torromeo@gmail.com>:
On Fri, Oct 21, 2011 at 2:07 PM, Gaetan Bisson <bisson@archlinux.org> wrote:
[2011-10-21 10:00:37 +0200] Massimiliano Torromeo:
If the sizes of the packages are problematic that's a different issue.
Okay. Suppose that issue isn't entirely theoretical. How do we solve it?
-- Gaetan
Well, first we should define why it is an issue.
As every _replacement_ it will be an issue, people used to the old way will complain to the new way (in this case games). If the new game is enough mature, have many servers, etc, then for me the "public" of that game is getting used and you should totally bring the new one, instead of that, stick with the old until the new one will became the actual one. For me, considering having the two games on the repos, yes is excessive, as i've manifested several times, i prefeer to see 1 GB in libraries of a language program instead of 1 GB used in an old deprecated (according to their authors) games. And.. Sergej, please try to focus on the problem that brings having huge packages and add the fact if those huge packages won't be demanded it will be a waste of space + mirror bandwidth. Just my 10 AR$ (yes, that was the cost of the coffee that I paid while I used the internet of that store to reply this mail :D) -- Angel Velásquez angvp @ irc.freenode.net Arch Linux Developer / Trusted User Linux Counter: #359909 http://www.angvp.com
At Fri, 21 Oct 2011 10:43:12 -0300, Ángel Velásquez <angvp@archlinux.org> wrote:
And.. Sergej, please try to focus on the problem that brings having huge packages and add the fact if those huge packages won't be demanded it will be a waste of space + mirror bandwidth.
Is it really problem? I have no info about disk space and bandwitdth problems. If yes, we should define what does "huge" means. And should we apply "huge" criteria only to games?
How about a [bloat] repo for packages over 512MB. - A
"Alexander Rødseth" <rodseth@gmail.com> wrote:
How about a [bloat] repo for packages over 512MB.
- A
That wouldn't really solve any problems though. Sigurd would host that repo nonetheless so the same restrictions apply. -- Sven-Hendrik
On 21/10/11 15:21, Sven-Hendrik Haase wrote:
"Alexander Rødseth"<rodseth@gmail.com> wrote:
How about a [bloat] repo for packages over 512MB.
- A That wouldn't really solve any problems though. Sigurd would host that repo nonetheless so the same restrictions apply.
-- Sven-Hendrik I am not sure why direct donnations are no longer accepted, but especially now, when Arch's popularity is raising rapidly, [5th place at distrowatch] I think it would be suitable to launch them again.
Linux Mint for example, is able to cover the majority of their server costs through subscribers and donors. Why not Arch? Is this somehow conflicting the Arch Way? I think at least for a dedicated server[s] for large and often downloaded packages this could work. -- Best Regards, Matej Ľach e-mail: contact@matej-lach.net web: www.matej-lach.net Use Arch Linux on your desktop and CyanogenMod on your mobile device!
Why not have a subscribe-only repository for very big packages? The PKGBUILDs can still be used directly, so no one loses. Another possibility is having pacman download and package static data from upstream directly at install-time. On 21-10-2011 11:30, Matej Ľach wrote:
On 21/10/11 15:21, Sven-Hendrik Haase wrote:
"Alexander Rødseth"<rodseth@gmail.com> wrote:
How about a [bloat] repo for packages over 512MB.
- A That wouldn't really solve any problems though. Sigurd would host that repo nonetheless so the same restrictions apply.
-- Sven-Hendrik I am not sure why direct donnations are no longer accepted, but especially now, when Arch's popularity is raising rapidly, [5th place at distrowatch] I think it would be suitable to launch them again.
Linux Mint for example, is able to cover the majority of their server costs through subscribers and donors. Why not Arch? Is this somehow conflicting the Arch Way?
I think at least for a dedicated server[s] for large and often downloaded packages this could work.
Am 21.10.2011 15:57, schrieb Sergej Pupykin:
At Fri, 21 Oct 2011 10:43:12 -0300, Ángel Velásquez <angvp@archlinux.org> wrote:
And.. Sergej, please try to focus on the problem that brings having huge packages and add the fact if those huge packages won't be demanded it will be a waste of space + mirror bandwidth.
Is it really problem? I have no info about disk space and bandwitdth problems.
If yes, we should define what does "huge" means. And should we apply "huge" criteria only to games?
Resources are always limited. There are disk space constraints on sigurd (which holds the AUR and community repo). You may add about 5 to 10GB packages here. And don't forget that you also have to host the sources for e.g. GPL packages. Bandwidth for our main server is also very limited. But if those big packages don't get updated to often this is acceptable. Let's also not forget about our mirrors who will have to handle the increasing needs for disk space and especially bandwidth and traffic. Especially for those countries where these resources are not cheap. E.g. we were told that mirrors in South Amercia dropped Arch for these reasons. Long story short: I would ask the TUs to use their resources more responsible. Of course we can talk about increasing disk space etc. if really needed but this wont help for long if everybody thinks there were no limitations. Maybe it would be wise to decide on an upper bound for the community repo size and to operate within this limitation. But this should be handled within the TU group; I just wanted to make aware of a potential problem. Greetings, Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre
On Fri, 21 Oct 2011 17:43:57 +0200 Pierre Schmitz <pierre@archlinux.de> wrote:
Am 21.10.2011 15:57, schrieb Sergej Pupykin:
At Fri, 21 Oct 2011 10:43:12 -0300, Ángel Velásquez <angvp@archlinux.org> wrote:
And.. Sergej, please try to focus on the problem that brings having huge packages and add the fact if those huge packages won't be demanded it will be a waste of space + mirror bandwidth.
Is it really problem? I have no info about disk space and bandwitdth problems.
If yes, we should define what does "huge" means. And should we apply "huge" criteria only to games?
Resources are always limited. There are disk space constraints on sigurd (which holds the AUR and community repo). You may add about 5 to 10GB packages here. And don't forget that you also have to host the sources for e.g. GPL packages. Bandwidth for our main server is also very limited. But if those big packages don't get updated to often this is acceptable.
Let's also not forget about our mirrors who will have to handle the increasing needs for disk space and especially bandwidth and traffic. Especially for those countries where these resources are not cheap. E.g. we were told that mirrors in South Amercia dropped Arch for these reasons.
Long story short: I would ask the TUs to use their resources more responsible. Of course we can talk about increasing disk space etc. if really needed but this wont help for long if everybody thinks there were no limitations. Maybe it would be wise to decide on an upper bound for the community repo size and to operate within this limitation.
But this should be handled within the TU group; I just wanted to make aware of a potential problem.
Greetings,
Pierre
A mirror is not obliged to mirror all our repositories, right? I would not cripple our package set because some mirrors can't deal with it. Rather: package all games you want to package, mirrors can decide not to mirror the community repo if they don't like it. Dieter
Am 21.10.2011 18:04, schrieb Dieter Plaetinck:
On Fri, 21 Oct 2011 17:43:57 +0200 A mirror is not obliged to mirror all our repositories, right? I would not cripple our package set because some mirrors can't deal with it. Rather: package all games you want to package, mirrors can decide not to mirror the community repo if they don't like it.
Dieter
Mirrors have to mirror everything as is. Excluding the whole community repo does not make much sense imho. I'd prefer to keep it easy and treat all our repo as one entity. And due to our package pool structure we cannot split out a single repo. E.g. community and multilib repos use the same package pool. -- Pierre Schmitz, https://users.archlinux.de/~pierre
Pierre Schmitz <pierre@archlinux.de> wrote:
Am 21.10.2011 15:57, schrieb Sergej Pupykin:
At Fri, 21 Oct 2011 10:43:12 -0300, Ángel Velásquez <angvp@archlinux.org> wrote:
And.. Sergej, please try to focus on the problem that brings having huge packages and add the fact if those huge packages won't be demanded it will be a waste of space + mirror bandwidth.
Is it really problem? I have no info about disk space and bandwitdth problems.
If yes, we should define what does "huge" means. And should we apply "huge" criteria only to games?
Resources are always limited. There are disk space constraints on sigurd (which holds the AUR and community repo). You may add about 5 to 10GB packages here. And don't forget that you also have to host the sources for e.g. GPL packages. Bandwidth for our main server is also very limited. But if those big packages don't get updated to often this is acceptable.
Let's also not forget about our mirrors who will have to handle the increasing needs for disk space and especially bandwidth and traffic. Especially for those countries where these resources are not cheap. E.g. we were told that mirrors in South Amercia dropped Arch for these reasons.
Long story short: I would ask the TUs to use their resources more responsible. Of course we can talk about increasing disk space etc. if really needed but this wont help for long if everybody thinks there were no limitations. Maybe it would be wise to decide on an upper bound for the community repo size and to operate within this limitation.
But this should be handled within the TU group; I just wanted to make aware of a potential problem.
Greetings,
Pierre
-- Pierre Schmitz, https://users.archlinux.de/~pierre
I was very aware of these limitations (and this exact issue has come up a few times in the past) and thus I asked for opinions on replacement on this list and didn't just blindly add the package. I also hoped we wouldn't have to discuss this again due to me wanting to either replace it or keep it like it is. I was not suggesting to have both packages. Things went a little off-topic here. As it stands, it looks like xonotic devs would be a lot happier if I replaced nexuiz and eventually players would be too. AUR sounds like a fine place for nexuiz. -- Sven-Hendrik
On Oct 21, 2011 11:30 AM, "Sven-Hendrik Haase" <sh@lutzhaase.com> wrote:
As it stands, it looks like xonotic devs would be a lot happier if I replaced nexuiz and eventually players would be too. AUR sounds like a fine place for nexuiz.
-- Sven-Hendrik
Coming from an external (user) perspective, I think some confusion may have been derived from the use if the term "replace" in this thread. If my understanding is correct you are suggesting that xonotic would "replace" nexuiz in the sense that xonotic moves to community and nexuiz drops to the aur. Not that xonotic gets marked as replaces=("nexuiz") such that nexuiz users are moved to xonotic on their next upgrade.
From an end-user perspective I see very little loss, and a potential considerable gain from this move. Given that the nexuiz package has not been update in nearly 2 years (the data package even longer), and upstream is effectively dead, the user will not likely have to build it more than once. Neither are existing users likely to miss an update because it moved. Xonotic on the other hand has been updated within the last month and and is likely to continue to be update, so significant time and effort could be saved for the users with not having to build each update.
More frequent updates with xonotic will mean more bandwidth usage however, so if this is the bigger concern then perhaps it is best to leave things as they are, or even drop nexuiz to aur anyway to free up the space with little loss. Just my humble 2¢ -- Sean Bogie
Sven-Hendrik Haase wrote:
I'd like to see nexuiz replaced by xonotic in [community]. Problem is that nexuiz is still a fairly popular package despite being dead upstream. xonotic devs recommend dropping nexuiz in favor of xonotic. Technically, xonotic does not replace nexuiz because its gameplay is somewhat different.
I'd like some opinions on this.
Quick history: Xonotic was forked from Nexuiz due to political reasons. It was originally meant to be nothing more than a name-change, but the transition brought in new influences and many (imo) substantial changes have been made to the game, so it is no longer "just the next version of Nexuiz". Many consider the two different games now. As it stands, the well-known Nexuiz servers are still very active. From what I've seen and heard, the Xonotic servers are much less active, and many players there are allegedly on non-public pickup servers. Of course, the continued presence of Nexuiz in most distro repositories contributes to this. I suggest keeping both Nexuiz and Xonotic until the main Nexuiz servers switch over to Xonotic, which they are supposed to with one of the upcoming major releases of Xonotic. As for the size, most of it comes from the game data archive in the package. The only compiled code are the client and server binaries, which are small and compile quickly. The ideal way to distribute such packages would be through a "trusted AUR". Then again, compressing a huge (already compressed) file into a package takes a long time, so it offsets the short compile time. Of course, the ideal would be for "makepkg -i" to just skip the redundant compression. Gah, so many coding idea, yet no time... *sigh* /rambling Regards, Xyne
participants (13)
-
Alexander Rødseth
-
Dieter Plaetinck
-
Gaetan Bisson
-
Ionut Biru
-
Marco Schulze
-
Massimiliano Torromeo
-
Matej Ľach
-
Pierre Schmitz
-
Sean Bogie
-
Sergej Pupykin
-
Sven-Hendrik Haase
-
Xyne
-
Ángel Velásquez