Re: Fwd: Bug#405997: should executables be permitted to update themselves?
For custom distros that provide their own updates, you are better off
disabling the core updater functionality of azureus. The best way in my
experience would be to prevent the CoreUpdateChecker and
CorePatchChecker from loading. Paul might have a better suggestion.
I've attached a diff which removes these two plugins.
With this patch users would still get plugin update notices. AFAIK,
users will still get a SWT library update notification if we require a
new SWT version. If you provide your own SWT library in a common
directory, I believe the user just gets a warning something to the
affect of "azureus wants a newer SWT version but you have it in a non-az
dir, so you must do it manually"
Also, as a heads up, we will be releasing a 2.5.0.4 within a week to
address some issues introduced in 2.5.0.2 (One of the fixed issues might
affect debian.. a lot of unix-type OSes are exhibiting large icons in
the torrent lists)
Of course, patches to Azureus are also welcome :)
-ArronM/TuxPaper
Azureus Team wrote:
> ---------- Forwarded message ----------
> From: Shaun Jackman <sjackman@gmail.com>
> Date: Jan 16, 2007 9:34 AM
> Subject: Re: Bug#405997: should executables be permitted to update
> themselves?
> To: Michael Gilbert <michael.s.gilbert@gmail.com>, 405997@bugs.debian.org
> Cc: debian-policy@lists.debian.org, Azureus Team <azureus@gmail.com>
>
>
> On 1/15/07, Michael Gilbert <michael.s.gilbert@gmail.com> wrote:
> ...
>> the user did not initiate the action. azureus went out and checked for
>> updates, then told the user that they should update. and it does this
>> every
>> time the application starts up unless the user chooses to update (at that
>> point, i don't think it is choice because the user can either say
>> "yes" and
>> get rid of the annoyance or continue to be annoyed). i understand
>> that we
>> should not attempt to limit anyone's freedom of choice, and we are
>> not. we
>> are preserving the security, quality, and maintainability of the
>> packages as
>> distributed and supported by debian. it is still possible for the
>> user to
>> choose to download the upstream jar, and run with "java azureus.jar"
>> if they
>> so choose. they also have an alternative choice to use the newer azureus
>> from sid via apt-pinning. i am not suggesting we prevent either of those
>> options.
>
> It is only possible for the user to download the upstream jar and run
> 'java azureus.jar' at the command line if he or she is technically
> capable of it. Presenting a technically-more-difficult `alternative'
> is no alternative at all. Ditto for the apt-pinning suggestion.
>
> I do agree that it would be better if the update dialog had all three
> options `Download update now', `Remind me later' and `Never update'
> options. A patch is welcome.
>
> Cheers,
> Shaun
>
>
### Eclipse Workspace Patch 1.0
#P SF AZ
Index: azureus2/org/gudy/azureus2/pluginsimpl/local/PluginInitializer.java
===================================================================
RCS file: /cvsroot/azureus/azureus2/org/gudy/azureus2/pluginsimpl/local/PluginInitializer.java,v
retrieving revision 1.92
diff -u -r1.92 PluginInitializer.java
--- azureus2/org/gudy/azureus2/pluginsimpl/local/PluginInitializer.java 16 Nov 2006 21:41:25 -0000 1.92
+++ azureus2/org/gudy/azureus2/pluginsimpl/local/PluginInitializer.java 17 Jan 2007 23:24:14 -0000
@@ -121,16 +121,6 @@
"azbpmagnet",
"Magnet URI Handler",
"true" },
- { PluginManagerDefaults.PID_CORE_UPDATE_CHECKER,
- "org.gudy.azureus2.update.CoreUpdateChecker",
- "azbpcoreupdater",
- "CoreUpdater",
- "true" },
- { PluginManagerDefaults.PID_CORE_PATCH_CHECKER,
- "org.gudy.azureus2.update.CorePatchChecker",
- "azbpcorepatcher",
- "CorePatcher",
- "true" },
{ PluginManagerDefaults.PID_PLATFORM_CHECKER,
"org.gudy.azureus2.platform.win32.PlatformManagerUpdateChecker",
"azplatform2",
Reply to: