[bug#45954] Telegram-CLI (v7)

[Raghav Gururajan]

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.

OpenPGP_0x5F5816647F8BE551.asc
Description: application/pgp-keys

OpenPGP_signature
Description: OpenPGP digital signature