Bug#1008644: ITP: nala -- commandline frontend for the apt package manager
Package: wnpp Severity: wishlist Owner: Blake Lee X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: nala Version : 0.7.1 Upstream Author : Blake Lee * URL : https://gitlab.com/volian/nala * License : GPLv3+ Programming Lang: Python Description : commandline frontend for the apt package manager nala is a frontend for the apt package manager. It has a lot of the same functionality, but formats the output to be more human readable. Also implements a history function to see past transactions and undo/redo them. Much like Fedora's dnf history. This package is useful because it improves the UX of managing packages through the command line with python3-apt. Additionally provides some extra quality of life features such as a transaction history you can interact with. I use nala daily, as do many others. Similar packages include apt and aptitude. Nala improves upon the hardwork of the apt team by formatting the output in a more readable manner. At the moment I maintain this program on our GitLab. That is where we accept bug reports and feature requests. I don't have any problems accepting bug reports from Debian's system, or emails for that matter. I regularly accept bug reports from our GitHub as well. We currently have support for the German language, and I have someone working on a Spanish po file as well. Nala is still in active development, but it is very usable. I've had many people ask me about getting this into the Official Debian repos so this is my request for that. I assume that I would be in need of a sponser considering I've never uploaded anything into a Debian repository. But I did try my best to make the debian files proper, and I personally use sbuild for building the software. In case it is required I do have our repo already mirrored into debian salse https://salsa.debian.org/volian-team/nala My users would be thrilled to hear this makes it into the official repositories. I'm looking forward to your response.
Re: Bug#1008644: ITP: nala -- commandline frontend for the apt package manager
Hi, Disclaimer: As I am an APT developer, I am feeling obligated to note that the following comment is just that, not an endorsement nor a review. I am also not indicating interest or what not. It is just a comment. On Tue, Mar 29, 2022 at 09:35:27PM -0400, Blake Lee wrote: > This package is useful because it improves the UX of managing packages > through the command line with python3-apt. Additionally provides some (improves… tastes are very different I guess, but that is fine. It reminds me of an unfinished branch though… a well, one day.) > extra quality of life features such as a transaction history you can The README describes it as using /var/lib/nala/history.json, libapt has /var/log/apt/history.log with I suppose roughly the some content, although we don't have IDs in there and removing entries would be strange. We have no interface for it so far though as we are as usual chronically understaffed. Anyway, 'undo' in relation to Upgrades triggers my spider-senses as downgrades are in general not supported. The screenshots avoid that problem supposedly by being only about installing a bunch of new packages and eventually removing these packages again. > […] Nala improves upon the hardwork of the apt […] You don't mention it here, but the README features it first (after the UI thing): Parallel Downloads. My personal opinion on opening multiple connections to the same server for parallel downloads aside, the bigger improvement seems to be that you can use multiple different mirrors… except that all libapt client can do that assuming you configure it: apt-transport-mirror(1). (or the packages come from different sources to begin with). As your entire downloading and verification process is written by you rather than using libapt I would prefer a note here mentioning this. I am of course totally biased, but I have seen enough "apt-fast" variants doing this completely wrong while unsuspecting users were under the impression that its just some shiny frontend on top of the good old battle tested libapt implementations. (Again, see Disclaimer. This is not a security review. I also don't want to imply that you have security bugs. Heck, perhaps libapt has more. My point is entirely on: Please be upfront on rolling your own) > Nala is still in active development, but it is very usable. I've had > many people ask me about getting this into the Official Debian repos so > this is my request for that. > > I assume that I would be in need of a sponser considering I've never > uploaded anything into a Debian repository. But I did try my best to > make the debian files proper, and I personally use sbuild for building > the software. That is two different things. A request to get it into Debian is a Request For Packaging (RFP) – any user can ask and if the stars align perhaps someone finds it useful enough to also want it in Debian with the additional motivation to maintain the package within Debian and wants to claim the work for themselves. That is what an Intend to Package (ITP) is for. Writing debian/ once is easy enough, the hard part is maintaining it over time. I (well, Julian I guess, as I don't speak Python) will e.g. pester the maintainer for this package in transitions to adapt to our newer APIs. So will the Python teams. That might or might not align with upstream work. In the mean time you as the maintainer (if upstream hasn't) are supposed to interact with the security team. Your 'critical' bugfix in v0.6.0 e.g. is a bug worthy of a CVE and would need to be backported into older versions for stable and every other release supported by Debian (ideally with coordination with the other distros with embargos and such). If Upstreams solution to that problem was so far to "just upgrade to the newest version" at least one of you is in for some work (I know you are both, its just easier to realize that these are two different jobs if we pretend you are not). And last but not least: If you decide you want to be a maintainer, head over to debian-mentors and read about Requests For Sponsorship (RFS) which helps you getting your ITP package you prepared into Debian while you are still learning the ropes and hence do not have rights to upload unsupervised into Debian yourself yet. (As this is python, the python team might be interested in helping maintaining it if you apply to them. While I would be happy if you would try to interact with us from the apt team, I don't think we have the resources to help you with packaging through.) Best regards David Kalnischkies signature.asc Description: PGP signature
Re: Bug#1008644: ITP: nala -- commandline frontend for the apt package manager
(improves… tastes are very different I guess, but that is fine. It reminds me of an unfinished branch though… a well, one day.) Yes, improves here is very subjective, I agree. Anyway, 'undo' in relation to Upgrades triggers my spider-senses as downgrades are in general not supported. I should probably update this in the readme, but rolling back upgrades is unsupported in Nala. You will receive an error if you run `undo` on an upgrade transaction I have considered attempting to implement this, but it does seem like a bad idea. Maybe one day with a warning and an explicit flag, but for now there is too much other work to do. As your entire downloading and verification process is written by you rather than using libapt I would prefer a note here mentioning this. I can definitely add a disclaimer saying that apt has no hand in downloading or verification when using Nala. (Again, see Disclaimer. This is not a security review. I also don't want to imply that you have security bugs. Heck, perhaps libapt has more. My point is entirely on: Please be upfront on rolling your own) Nala is still in active development, but it is very usable. I've had many people ask me about getting this into the Official Debian repos so this is my request for that. I assume that I would be in need of a sponser considering I've never uploaded anything into a Debian repository. But I did try my best to make the debian files proper, and I personally use sbuild for building the software. Your 'critical' bugfix in v0.6.0 e.g. is a bug worthy of a CVE and would need to be backported into older versions for stable and every other release supported by Debian (ideally with coordination with the other distros with embargos and such). If Upstreams solution to that problem was so far to "just upgrade to the newest version" at least one of you is in for some work (I know you are both, its just easier to realize that these are two different jobs if we pretend you are not). There will definitely be a lot of things to get use to with having this in the main repositories. But I am willing and excited to learn. I have packaged a few things with quilt patches so I'm a little familiar on how that would go for backporting. And last but not least: If you decide you want to be a maintainer, head over to debian-mentors and read about Requests For Sponsorship (RFS) which helps you getting your ITP package you prepared into Debian while you are still learning the ropes and hence do not have rights to upload unsupervised into Debian yourself yet. (As this is python, the python team might be interested in helping maintaining it if you apply to them. While I would be happy if you would try to interact with us from the apt team, I don't think we have the resources to help you with packaging through.) I will find some time today to read up on this. I would like to be the maintainer as I think that may be the easiest path forward once I learn the ropes. Thanks, Blake