On 1/14/07, Linas Žvirblis <[EMAIL PROTECTED]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael Gilbert wrote:
> is there a policy on whether an executable is permitted to update
> itself?
Not sure about The Policy, but I can see a lot of reasons why this
should not be done:
1. The md5 sums will not match anymore, so one cannot
verify the integrity of the file.
The original copy is kept in /usr/. The updated copy is stored in
~/.azureus/. The user does not have write permissions to /usr/ and
doest not ask for them.
2. The actual version of application will be different
from the one reported by apt, so future upgrades may
actually downgrade the application.
apt will upgrade the /usr/ copy, but not the ~/.azureus/ copy.
3. Version information in bug reports may be wrong.
That's true. Good point.
4. The upstream build may not work because of mismatched
dependencies.
Java's pretty lax in that department. It hasn't been an issue so far.
5. The upstream build may introduce bugs.
True. It is possible to revert by removing ~/.azureus/.
6. The upstream build may not be DFSG free.
Absolutely not our concern. It is the user's choice as to which
software she wishes to download and run.
Sounds like reinventing the wheel, only the wheel is now square. Do not
do this, please.
On a stable Debian system, system-wide upgrades can be far between. I
prefer to give the user a choice of whether to use the update system
provided by the upstream author to update the software before the next
stable release of Debian.
Cheers,
Shaun
