[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Review of new English templates for scrcpy



Yangfl wrote:
> Ok, there is a major transition undergoing: scrcpy is moving to
> contrib and scrcpy-server removing due to inability to build within
> debian's android toolchain. So there is no scrcpy-server anymore.
> Users have to use "scrcpy-server" binary directly from upstream now.

Now it makes sense.  And you don't even need to worry about existing
users of scrcpy on stable being confused; we can assume anybody
installing it understands the situation.

>>>  .
>>>  If you choose "Yes", installer will download and install the server binary now,
>>>  and update it along with `scrcpy' upgrade. You have to have a decent toolkit to
>>>  do that, e.g. `wget', `curl', `ca-certificates', etc.
>>
>> If it needs them, shouldn't it depend on them?  Or does it mean they
>> need to be installed on the Android device?  (Wget *and* curl?)
> 
> They definitely need a downloader if they want the installer to
> download the binary for them. I prefer not to make them hard
> dependencies since users may want to use different methods to fetch
> the server (via a custom network proxy for example). In these cases,
> preselected downloaders may not be that useful.

It should probably be a Recommends given that the default choice here
needs them to be available...

>>>  If you choose "No", you will need to update the server yourself, located at
>>>  `/usr/share/scrcpy/scrcpy-server'. A convenient script
>>>  `/usr/libexec/scrcpy-update-server' is provided to do that. While scrcpy might
>>>  work with an outdated server, you might encounter wired problems without
>>>  getting any hint.
>>
>> Isn't the script for updating a Debian package meant to live in
>> /var/lib/dpkg/info/packagename.{pre,post}inst?  If on the other hand
>> I'm going to be running a non-Debian-packaged version, shouldn't it go
>> in /usr/local?
> 
> The script for apt upgrading is still postinst. Commands for
> downloading and cksumming are extracted into a seperate libexec script
> so that they can be reused if users decide not to install it during
> apt upgrading. I see msttcorefonts also installs 3rd binaries into
> /usr/share.

Yes, installing to /usr is fairly standard for contrib
installer-packages; but /usr/libexec in particular is supposed to be
for scripts that users *aren't* expected to run manually.

 
But meanwhile, here's a template review that tries to stick to
just reviewing the template...

> Template: scrcpy/update_server
> Type: boolean
> Default: true
> _Description: Auto update scrcpy server?

This sounds as if it's asking whether something should be updated, but
I can't update it yet - first I'd need to have an out-of-date version!

The line about dpkg-reconfigure implies it's going to remember that I
asked for automatic updates; you could imply that here by saying:

  _Description: Manage scrcpy server downloads automatically?

>  Please specify whether you want to download scrcpy server from the Internet
>  automatically, now and on every upgrade.
>  .
>  scrcpy cannot work without the server binary.

Presumably this is talking about "every upgrade" of the scrcpy
"client"?  So for a stable user, once every few years?

Reorder this to

   scrcpy cannot work without a copy of the /usr/share/scrcpy/scrcpy-server
   binary, which needs to be fetched from upstream.

   Please specify whether you want this to be done automatically every
   time scrcpy itself is upgraded.

What happens in 2026 when I'm installing scrcpy v1.99 on stable
Trixie, but the upstream version of scrcpy-server is the incompatible
v2.0?  Does the installer always *upgrade* to the newest version it
can find, or does it look for the *matching* server binary?

>  .
>  If you choose "Yes", installer will download and install the server binary now,
>  and update it along with `scrcpy' upgrade. You have to have a decent toolkit to
>  do that, e.g. `wget', `curl', `ca-certificates', etc.

One of the old rules of thumb for template reviews is that the
installer shouldn't mention "the installer".  (I joke that this is
because we don't want it to become self-aware.)  The user might be
reading this message as part of an initial Debian install, and doesn't
know whether you mean debian-installer, the APT install-scripts for
this particular package, or your special download-from-upstream
script.  A related rule is that we should avoid assuming that debconf
is offering buttons marked "Yes" and "No".

   If you accept this option, the server binary will be downloaded during
   the installation of scrcpy. This will fail if tools such as wget, curl,
   ca-certificates, etc. are not available.

(Or if those tools are pulled in by Recommends and the script gives
helpful error messages you could probably skip the second sentence.)

>  .
>  If you choose "No", you will need to update the server yourself, located at
>  `/usr/share/scrcpy/scrcpy-server'. A convenient script
>  `/usr/libexec/scrcpy-update-server' is provided to do that. While scrcpy might
>  work with an outdated server, you might encounter wired problems without
>  getting any hint.

   If you reject this option, you will need to fetch the server binary
   manually, for instance by using "/usr/libexec/scrcpy-update-server"
   yourself. While scrcpy might work with an outdated server, this can
   cause hard-to-debug problems.

Or possibly

   If you reject this option, you will need to fetch the appropriate
   server binary manually, for instance by using 
   "/usr/libexec/scrcpy-update-server" yourself. While scrcpy might
   work with a server with a different version number, this can cause
   hard-to-debug problems.

(But my patch optimistically assumes the first version.)

>  .
>  You can change your choice later with `sudo dpkg-reconfigure scrcpy'.

   You can change your choice later with "sudo dpkg-reconfigure scrcpy".

Patch attached.
-- 
JBR	with qualifications in linguistics, experience as a Debian
	sysadmin, and probably no clue about this particular package
--- template.old	2024-08-16 15:56:16.338822280 +0100
+++ template.new	2024-08-16 16:47:14.757679553 +0100
@@ -1,21 +1,21 @@
 Template: scrcpy/update_server
 Type: boolean
 Default: true
-_Description: Auto update scrcpy server?
- Please specify whether you want to download scrcpy server from the Internet
- automatically, now and on every upgrade.
+_Description: Manage scrcpy server downloads automatically?
+ scrcpy cannot work without a copy of the /usr/share/scrcpy/scrcpy-server
+ binary, which needs to be fetched from upstream.
  .
- scrcpy cannot work without the server binary.
+ Please specify whether you want this to be done automatically every
+ time scrcpy itself is upgraded.
  .
- If you choose "Yes", installer will download and install the server binary now,
- and update it along with `scrcpy' upgrade. You have to have a decent toolkit to
- do that, e.g. `wget', `curl', `ca-certificates', etc.
+ If you accept this option, the server binary will be downloaded during
+ the installation of scrcpy. This will fail if tools such as wget, curl,
+ ca-certificates, etc. are not available.
  .
- If you choose "No", you will need to update the server yourself, located at
- `/usr/share/scrcpy/scrcpy-server'. A convenient script
- `/usr/libexec/scrcpy-update-server' is provided to do that. While scrcpy might
- work with an outdated server, you might encounter wired problems without
- getting any hint.
+ If you reject this option, you will need to fetch the server binary
+ manually, for instance by using "/usr/libexec/scrcpy-update-server"
+ yourself. While scrcpy might work with an outdated server, this can
+ cause hard-to-debug problems.
  .
- You can change your choice later with `sudo dpkg-reconfigure scrcpy'.
+ You can change your choice later with "sudo dpkg-reconfigure scrcpy".
 

Reply to: