[bug#45954] Telegram-CLI (v7)

[Raghav Gururajan <rg@raghavgururajan.name>]

[-- Attachment #1.1.1: Type: text/plain, Size: 2235 bytes --]

Hi Leo!

> I didn't notice this before, but is there a reason to package this
> version over 1.3.1?

Yeah, there are quite a lot of improvements after the 1.3.1 release.

> Please stop trying to use this as a snippet to mean "the root of the
> source and build directory".  It is extremely obscure and people are
> already using "../source" just fine.  (Just do an rgrep if you aren't
> convinced.)

Fixed in v8.

>> Hmm. I tried but couldn't come up with a way to do it like that. :(
> You can still try harder for v8 ;)

I tried different ways but the arguments key-words between gnu and copy 
differ a lot. I am unable use key-words from both build systems at the 
same time. Like using #:configure-flags (from gnu) and #:install (from 
copy).

Also, I spent significant amount time to come up the phase I have. So if 
there are no critical issues, I would like to keep it as-is. :-)

>> The script may only be used on foreign-distro for now. For guix
>> system,
>> we need to define a service for it.
>>
>> Also, running telegram-cli doesn't require daemon, but vice-versa.
>> The
>> daemon is intended to be a complimentary feature to run telegram-cli
>> on
>> headless server.
> In that case, does the daemon script have any value of its own?  Given
> that the latest release of telegram-cli is about six years old, I doubt
> there is – foreign distros should already have it in their repos and
> Guix as a package manager makes no claim to manage system stuff like
> services on foreign distros.
> 
>> The file is a run-time script.
> That means literally nothing.  The wrap phase exists for a reason, some
> programs and script are even wrapped twice.
> 
>> Using (getenv "PATH") will instead use the value of PATH inside the
>> build environment.
> So you'll inadvertently have some native-inputs in it, is what you're
> trying to say?  Of course, there are better ways of wrapping PATH, but
> in this case wouldn't it be wise to limit it to just the expected
> paths?  Again, assuming that there is even merit in shipping this file,
> which is yet to be proven.

I don't know what I was thinking. XD. It is pretty useless to ship. I 
removed it in v8.

Regards,
RG.

[-- Attachment #1.1.2: OpenPGP_0x5F5816647F8BE551.asc --]
[-- Type: application/pgp-keys, Size: 2649 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]