[Top][All Lists]

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

[bug#45954] Telegram-CLI (v7)

From: Raghav Gururajan
Subject: [bug#45954] Telegram-CLI (v7)
Date: Mon, 1 Feb 2021 21:33:43 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Icedove/78.6.1

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

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
we need to define a service for it.

Also, running telegram-cli doesn't require daemon, but vice-versa.
daemon is intended to be a complimentary feature to run telegram-cli
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.


Attachment: OpenPGP_0x5F5816647F8BE551.asc
Description: application/pgp-keys

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]