Thomas Koch <thomas@koch.ro> writes: > There will surely be better examples that can't be solved by just denying > their usability for a wider audience. > Sure, a good example is the helpfully named "s", which is a single source file of about 20k, but depended on by many other elpa packages. > So: > - one debian package per elpa package? This is my personal preference; it's also the only case currently supported by dh-elpa (to be precise, one binary package per elpa package). I think some moderate number of "core" packages this probably makes sense. Hopefully ftp-masters can be convinced. In general I think we (the Debian project) should focus on how useful a package is, not directly on it's size. For leaf packages of marginal global interest, I'd be inclined to let people grab them from upstream packaging; I'm not sure there's much value added by having a Debian package (at least if/when upstream package signing is working). It's only a few keystrokes to install packages from elpa / marmalade / melpa-stable. So why don't I like cluster packages (for want of a better term)? This is all from memory, so maybe other people have good solutions for some of these issues. - maintainability. I'm not aware of any examples of well maintained cluster packages. This isn't a criticism of any particular maintainers; pkg-perl has probably the best record as a team maintaining packages, but even there the record of keeping things up to date is not great. - tooling. I think part of the reason for the above is that it seems every cluster package is it's own special snowflake. Of course someone (TM) could develop tools for better managing clusters, but in the last few decades that hasn't happened. - discoverability. It's not so much harder to use search rather just know the name of the package, but it is a small irritation for a user (or upstream author). Perhaps more importantly, it substantially complicates writing tools like dh-make-perl that automatically translate elpa dependencies into debian ones. - version conflicts. if A version X and B version Y are packaged together, then then e.g. the user that needs a version of A > x can install their own. If they need a version < X, they are basically out of luck, and the larger the cluster the worse the potential impact of removing the cluster package in order to install a private version of A. OK, this message is getting pretty long. The TL;DR is that I'm personally not going to work on cluster packages or put a lot of work into tooling for them. If that means some things don't get packaged in Debian, then I can live with that. d
Attachment:
signature.asc
Description: PGP signature