[aur-general] Deletion Request
Hi, i'd like to request that the atheme-services [1] package (that i maintain) be deleted from the AUR as atheme-services upstream [2] requests that distros not package it. Thanks JD [1] : http://aur.archlinux.org/packages.php?ID=18664 [2] : http://atheme.net/
On Thu, May 27, 2010 at 2:31 AM, Jeff Horelick <jdhore1@gmail.com> wrote:
Hi, i'd like to request that the atheme-services [1] package (that i maintain) be deleted from the AUR as atheme-services upstream [2] requests that distros not package it.
Thanks JD
[1] : http://aur.archlinux.org/packages.php?ID=18664 [2] : http://atheme.net/
Done. Thanks!
Am 27.05.2010 01:34, schrieb Evangelos Foutras:
[2] : http://atheme.net/
Done. Thanks!
Hello, I think this is a very strange attitude for an open source project. I am fine with removing it. Regards Stefan
On 27 May 2010 15:57, Stefan Husmann <stefan-husmann@t-online.de> wrote:
Am 27.05.2010 01:34, schrieb Evangelos Foutras:
[2] : http://atheme.net/
Done. Thanks!
Hello,
I think this is a very strange attitude for an open source project. I am fine with removing it.
Regards Stefan
This is entirely my personal opinion, but it makes it a hassle if the package is the stable version (for example) and users being a bit stupid with wanting a feature in the testing/hg version, but being super-anal about using their distro's package. That's just an annoyance, but...Most distro packages of software put stuff where you'd expect it according to the FHS, but they all put it in slightly different places. I forget for this package, but on Arch, the atheme.conf might be in /etc/ whereas on Debian it might be in /etc/atheme/ and the atheme.db might be anywhere in /var/. With not packaging it, the Atheme developers can say: "OK, the DB is at ~/atheme/etc/atheme.db and the .conf is at ~/atheme/etc/atheme.db" and unless the user changed the prefix (which...Then they probably shouldn't be asking where the .conf and stuff is) , that'll always be correct. Also, and this is less of an issue with Arch because things are updated quickly and i was the package maintainer and i'm also an upstream atheme developer, but most IRC stuff is volatile. I've got a Debian Stable server and i'm using the old version of Cherokee and formerly Apache just fine, but i wouldn't recommend users to use Atheme 3.0.4 (the version currently in Debian Stable) because of many bugfixes and little support for quite new IRCd's. Sorry if this came off a bit ranty/incoherent (i'm a bit under the weather), but that's my stance and the official Atheme stance and i personally agree with it.
Am 29.05.2010 01:24, schrieb Jeff Horelick:
On 27 May 2010 15:57, Stefan Husmann<stefan-husmann@t-online.de> wrote:
Am 27.05.2010 01:34, schrieb Evangelos Foutras:
[2] : http://atheme.net/
Done. Thanks!
Hello,
I think this is a very strange attitude for an open source project. I am fine with removing it.
Regards Stefan
This is entirely my personal opinion, but it makes it a hassle if the package is the stable version (for example) and users being a bit stupid with wanting a feature in the testing/hg version, but being super-anal about using their distro's package.
That's just an annoyance, but...Most distro packages of software put stuff where you'd expect it according to the FHS, but they all put it in slightly different places. I forget for this package, but on Arch, the atheme.conf might be in /etc/ whereas on Debian it might be in /etc/atheme/ and the atheme.db might be anywhere in /var/.
With not packaging it, the Atheme developers can say: "OK, the DB is at ~/atheme/etc/atheme.db and the .conf is at ~/atheme/etc/atheme.db" and unless the user changed the prefix (which...Then they probably shouldn't be asking where the .conf and stuff is) , that'll always be correct.
Also, and this is less of an issue with Arch because things are updated quickly and i was the package maintainer and i'm also an upstream atheme developer, but most IRC stuff is volatile. I've got a Debian Stable server and i'm using the old version of Cherokee and formerly Apache just fine, but i wouldn't recommend users to use Atheme 3.0.4 (the version currently in Debian Stable) because of many bugfixes and little support for quite new IRCd's.
Sorry if this came off a bit ranty/incoherent (i'm a bit under the weather), but that's my stance and the official Atheme stance and i personally agree with it.
Hello, sorry, that does not convince me. With that argumentation we could declare 90 % of the software projects as not to be packaged. Saying, "please do not package it", together with the reason on the homepage, means to me the same as "please do not bother us, we are not interested in users". This is rude. Personally I do not, with very few exceptions (scripts I wrote myself, some emacs-stuff), use unpackaged software installed in ~. I cannot recommend users to do so. Therefore I am fine with removing Atheme from AUR. Just My personal opinion. Regards Stefan
On 05/29/10 00:37, Stefan Husmann wrote:
sorry, that does not convince me. With that argumentation we could declare 90 % of the software projects as not to be packaged.
This project in particular is interesting, since not many installations use it. For example, Freenode uses it (one installation, to service that whole network, I guess...). Whereas there are probably millions of Apache installations. I wonder how that figures into things... -Isaac
On 05/28/10 19:24, Jeff Horelick wrote:
Also, and this is less of an issue with Arch because things are updated quickly and i was the package maintainer and i'm also an upstream atheme developer, but most IRC stuff is volatile.
I admit to be confused by this assertion... as far as I know, XChat for example is an incredibly stable and rather unchanging piece of software, and also I didn't realize there was possibility for there to be much innovation on the server side, let alone necessity (suggested by "volatile"). I'm curious!
On 29 May 2010 00:52, Isaac Dupree <ml@isaac.cedarswampstudios.org> wrote:
On 05/28/10 19:24, Jeff Horelick wrote:
Also, and this is less of an issue with Arch because things are updated quickly and i was the package maintainer and i'm also an upstream atheme developer, but most IRC stuff is volatile.
I admit to be confused by this assertion... as far as I know, XChat for example is an incredibly stable and rather unchanging piece of software, and also I didn't realize there was possibility for there to be much innovation on the server side, let alone necessity (suggested by "volatile"). I'm curious!
Appears I mis-spoke a bit (as I mentioned, under the weather :P). Its more that IRC Services (and to a lesser extent, IRCd's) are volatile. Let's say you choose to run Freenode's IRCd, ircd-seven on your IRC network...Well, for a bunch of the features to work, you'll need to run Atheme 4.0, if not 5.0. If you choose to run InspIRCd 1.2 (which is currently the recommended version of inspircd), you'll need Atheme 5.0. As far as IRCd's, I currently work on another project called ShadowIRCd and if someone was running 6.0.0 which is only ~3 months old, i'd highly suggest for them to upgrade to 6.0.1 or the 6.1 series. I know InspIRCd is similar to this, as soon as they released their 1.2.0 version, the 1.1 series sort of lost support. Granted, this is only 2 or 3 cases and you can point at some pretty obvious alternate cases like for IRCd's, stuff like charybdis and ratbox that only release once every 6 months (if that) and there's no real need to upgrade unless you want a specific new feature or something and there's UnrealIRCd that's pretty much the same way but with an even longer release period.
participants (4)
-
Evangelos Foutras
-
Isaac Dupree
-
Jeff Horelick
-
Stefan Husmann