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
Attachment:
signature.asc
Description: PGP signature