On Fri, 20 Jun 2008, Daenyth Blank wrote:
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.
We are currently in the process of adding new devs. If none of them wants
to maintain azureus, then it'll be moved to unsupported.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
