[bug#54974] [PATCH] added btop

[Wil deBeest <bovid-19@4tii.de>]

Maxime Devos <maximedevos@telenet.be> writes:

> [[PGP Signed Part:Undecided]]
> Wil deBeest schreef op vr 29-04-2022 om 01:17 [+0200]:
>> Hi Maxime,
>>> Long term, %outputs, %build-inputs, ... are being phased out, so I'd go
>>> with, so I'd go with
>>>    (arguments (list #:make-flags #~(string-append "PREFIX=" #$output)))
>>> here instead.
>> I haven't been able to integrate your snippet into the package.   Could you
>> show me how to do so or tell me which part of the handbook would be
>> relevant?
> 
> For a good example, see the 'stress-ng' package definition 'guix edit
> stress-ng'.  #:make-flags is documented in the manual (search for
> #:make-flags or go to (guix)Build Systems).  #$output is documented in
> ‘(guix)G-Expressions’.
> 
> Very concretely:
> 
>  (package
>    [...]
>    (arguments (list #:tests? #false ; some comment
>                     #:make-flags #~(...)
>                     #:phases
>                     ;; [Stuff for replacing the install phase and
>                     ;; removing the configure phase]
>                     #~(modify-phases %standard-phases ...))))
> 
> Greetings,
> Maxime.
> 
> [[End of PGP Signed Part]]


Thank you, I think I got it.

I've also added gcc-12 as a native input for efficiency reasons [1].

Since I'm not familiar with the process of deprecation, I've kept the thoughts I had written down regarding your question on whether bashtop & bpytop could be removed, even though there's probably nothing in there that hasn't at least been discussed before [2]


Cheers!




---
gnu/packages/admin.scm | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)

diff --git a/gnu/packages/admin.scm b/gnu/packages/admin.scm
index af75dee697..fccc0e8dd3 100644
--- a/gnu/packages/admin.scm
+++ b/gnu/packages/admin.scm
@@ -101,6 +101,7 @@ (define-module (gnu packages admin)
  #:use-module (gnu packages file)
  #:use-module (gnu packages flex)
  #:use-module (gnu packages gawk)
+  #:use-module (gnu packages gcc)
  #:use-module (gnu packages gettext)
  #:use-module (gnu packages gl)
  #:use-module (gnu packages glib)
@@ -752,6 +753,37 @@ (define-public bpytop
@command{bashtop}.")
    (license license:asl2.0)))

+(define-public btop
+  (package
+    (name "btop")
+    (version "1.2.6")
+    (source
+     (origin
+       (method git-fetch)
+       (uri (git-reference
+             (url "https://github.com/aristocratos/btop")
+             (commit (string-append "v" version))))
+       (file-name (git-file-name name version))
+       (sha256
+        (base32
+         "03nd34q1w01visd2bg7mxrcjn0s6lnbm4s0vsfsj2mfv1rvyjl5b"))))
+    (native-inputs (list gcc-12))
+    (build-system gnu-build-system)
+    (arguments
+     (list #:make-flags
+       #~(list (string-append "PREFIX=" #$output))
+       #:phases
+       #~(modify-phases %standard-phases
+         (delete 'configure))
+        #:tests? #f))
+    (home-page "https://github.com/aristocratos/btop")
+    (synopsis "Resource monitor")
+    (description "Resource monitor that shows usage and stats
+for processor, memory, disks, network and processes.
+
+C++ version and continuation of bashtop and bpytop.")
+    (license license:asl2.0)))
+
(define-public pies
  (package
    (name "pies")

base-commit: 6e9d99f97f15347f44df0518faa5e3b8b9d5184e
-- 
2.36.1









[1] "Needs GCC 10 or higher, (GCC 11 or above strongly recommended for
better CPU efficiency in the compiled binary)", sayeth the readme

[2] Is there a mechanism to flag these packages so a deprecation warning
would be shown when they are searched for?  (A first look seems to
suggest `gexp->derivation' could be used for that, but I'll have read
that more thoroughly)

If there is I think it would make sense to add a deprecation warning
including that reasons why they shouldn't be replaced can be directed to
e.g. 54974@debbugs.gnu.org and wait for feedback for some set amount of
time before either redefining the package names as aliases for btop or
removing them.  In both cases I think a message would make sense for
those who have installed them.  For others, adding something like
"replaces its predecessors bashtop and bpytop" to the description seems
to be enough.