2008/6/20 Ondřej Kučera <ondrej.kucera@xxxxxxxxxx>: > On Sun, 13 Apr 2008 02:12:41 -0500 > Simo Leone <simo@xxxxxxxxxxxxx> wrote: > >> On Sat, Apr 12, 2008 at 01:48:58PM +0200, Jan de Groot wrote: >> > I could update it again. The reason for patching it during froscon >> > was that upstream azureus doesn't work with GNU java. >> > >> Why do we care? What's wrong with depending on Sun's java package? >> >> > Another thing was that >> > the jarfile contains a lot of Windows and Mac OS X related things, >> > the update manager doesn't work happily together with pacman >> > packages and the upstream distribution contains either outdated >> > copies of libraries where we have packages for, or just references >> > to outdated copies that are incompatible with our installed >> > versions. >> > >> Now some of that can be a problem. >> >> > I had a look at the source, I can reduce some patches, as most are >> > not needed anymore. Back then, I wrote two patches to remove some >> > com.sun.* usage, they don't apply anymore and I have to check if >> > they're still needed and if so, rewrite them. >> > >> See first response. >> >> > Another thing I stumbled on were the dependencies: >> > >=dev-java/bcprov-1.35:0 >> > >=dev-java/commons-cli-1.0:1 >> > >=dev-java/log4j-1.2.8:0 >> > >=dev-java/swt-3.4_pre6-r1:3.4 >> > >> > That's what gentoo lists as dependencies (there's no clear >> > reference of dependencies in the upstream source at all... just >> > compile errors with weird missing references when you don't have >> > these installed). >> > >> > -bcprov is packaged >> > -commons-cli isn't >> > -neither is log4j >> > -swt is at 3.3.x >> > >> > Azureus 3.0.5.0 needs swt 3.4 development version (3.4M6 is >> > current). If we don't want to update swt to the development >> > version, we're tied to the much older 3.0.4.2 release, which needs >> > some additional patches to compile from source. >> > >> > >> Augh. Maybe we should go back to using the ones included with the >> jarfile, since I think the java policy we've got is basically... >> "split it if you can, don't bother if it's a hassle". This is >> starting to sound like a hassle to me. >> >> -S > > I'll open this again... I think the main question now is - how many > Archers are actually interested in Azureus? I mean if I'm the only one > who uses it (or there's only a few of us), is there any reason for it > to be in [extra] (where it is unmaintained anyway), shouldn't it be > simple moved to unsupported (where someone would or wouldn't pick it > up)? Is there any way to find out how popular a package in [extra] is > (something like votes in AUR)? > > Anyway I created a new package in AUR, vuze (which is the new name of > Azureus, I didn't even know that) - > http://aur.archlinux.org/packages.php?ID=17932. It simply downloads the > latest binary version and puts it to /opt. It seems to work OK - at > least it starts and is able to start downloading a torrent of > ArchLinux's ISO. :-) The PKGBUILD is very basic for now, I just wanted > to know if anyone is actually interested at all (if you are, please > leave a comment and/or vote). It has the following limitations: > (1) Right now, only x86_64 is supported, some juggling similar to what > is done in PKGBUILD for Opera will be needed. > (2) Depends on jre. Perhaps it would be more correct to depend on > java-runtime but I don't have time to test it under java-gcj-compat. > (3) Perhaps it should provide azureus and conflict with azureus. It > doesn't have any conflicting files with the azureus package though. On > the other hand, using both might mess with $HOME/.azureus... > > Any comments? I really don't think that there should be a package in > core/extra/community unmaintained for such a long time. > > > -- > Cheers, > Ondřej Kučera > > Personally, due to the home clash, I would suggest that it conflict. According to PKGBUILD man page, it should also use replace=, because there's been a change in upstream naming. I'm hardly official, but it's been my experience that noone (In #archlinux) uses Azureus anyway, so I'd second a move out of extra.