Quoting Raphael Hertzog (2020-12-18 10:44:10) > On Fri, 18 Dec 2020, Jonas Smedegaard wrote: > > Who is keeping software out of Debian here? > > We, collectively, with the fact that we have not adapted our rules and > tooling. [ sorry I turned it personal! I mis-read your post as starting that ] I agree that some Debian packaging work is pretty time consuming. I agree that our tools can be improved. I disagree that our rules are outdated, and by extension disagree that our tools need adaptations that goes against our current rules. To me, Debian is essentially about curating and combining code projects into a single fully Free, coherent, and long-term maintainable system. We also do other things besides "a single fully Free, coherent, and long-term maintainable system" - some of it within our debian.org domain, some of it nearby in the debian.net domain or elsewhere. Yes, we also do non-free stuff, without releasing it as Debian. Yes, we also use lesser maintainable parts, not released as Debian. It seems you are arguing that Debian should change its rules to fit a World that is not long-term maintainable. I disagree - I think we should acknowledge that not everything can fit into Debian, but that does not mean Debian need to change. In fact, I find it *more* important to insist on the rules governing long-term maintenance when the outside World care less about that. > I'm not saying it's impossible, I'm saying it's not realistic for > volunteer maintainers, and even for the few that have the chance to be > paid for it, they can't justify the expense to do it following the > current rules and policies. I disagree that the issue here is volunteer time or "expenses" - the issue is that we deliberately and consciously want something that not everyone outside Debian wants: We want to be able to release a complete operating system and have it "stable" for several years. It is indeed not realistic to fit all fast-changing code projects into Debian. We have made a few fast-paced projects like Firefox fit, but in my opinion we did that in a problematic way: By endorsing embedded code copies, which is painful to maintain. I think we should not relax our rules, but (improve our packages so that we can) tighten our rules to apply more consistently - e.g. avoid embedded code copies also in Firefox. For fast-paced projects we already have contrib and other approaches, recognizing that not everything fits into Debian but is helpful to keep close. > > Or if you are talking about the Kali helper tool here, then please do > > share more details of that wonderful tool, so we can know if you are > > talking about a way to make the impossible-in-your-view possible while > > still complying with Debian Policy, or the wonder really is in an > > implied relaxing of packaging quality. > > There's no wonderful tool. It's just that we don't have the same > rules. And I don't agree that the "packaging quality" is worse in this > specific case. > > We have certainly made ugly things at times, but in this specific > case, relying on the uptsream build system is certainly not "bad > quality", the tool works and it likely works better when we can ensure > that we use the same set of libraries than upstream compared to the > random versions that happen to be in Debian at any given time. I don't share your certainty about the quality of Node.js dependency management - especially within a surrounding scope of a stable system. Also, I dislike your description of versions in Debian being "random". Technically it is wrong (but that's nitpicking), however my beef is that its seems to me that you really mean to say that the versions in Debian is badly curated: When upstream Node.js developers explicit (paraphrased) instructs to "process this snippet with Babel 7.2.11", the JavaScript team coerces that into "process this snippet with newest Babel available in Debian" - I don't call that "random" nor badly curated, I call that sensibly curated. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Attachment:
signature.asc
Description: signature