Quoting Andrew Lee (2026-09-29 14:59:31) > On Tue, Sep 29, 2026 at 2:45 PM Jonas Smedegaard <[email protected]> wrote: > > No, I have not checked the code. > > Please have a look so that you can answer my question correctly.
Sorry for my previous misunderstanding of the above remark: I will now look at the below (assuming that's what you meant) and answer based on that. > > It is permitted to package dead-end tools to "infect" users' systems > > with non-Debian tools, but what is your point in doing that? You cannot > > package any code that _needs_ vue if that package is only available > > through pulling it in from an external source. > > > > An example of dead-end helpers is the official Debian package rustup > > which is nice and convenient for users *not* caring about source, but > > totally useless for Debian developers for packaging anything depending > > on that side-installed tool. > > > > So back to your original question: Why do you ask? What is the aim? > > Thank you for checking my original question. > > My main goal is to build web front for a golang package. The is a > missing build-deps on vue3. Jermeny suggest to update vue.js 2.7 to > version 3.5 in Debian, and you asked me to make sure all the > reverse-dependency such as python-trame-client works correctly with > updated vue.js versoin 3.5. > > And my original question here: I wanted to ask if the way > python-trame-client currently handles its web app is fully compliant > with Debian policy. If this approach is acceptable, I am hoping to > follow the same method to build the web frontend for the golang > package, which would save me from having to package all of the missing > Node.js build-deps from scratch. Debian packages must include source, where compacted JavaScript code is not considered source. If your goal is to build a web front *locally* on your system, then it you can create an official Debian package containing a shell script that calls curl or wget to fetch vue somewhere on the internet, install that package, run that vue-fetcher, and build your web front. Such a package would in my understanding need to be placed in contrib (not main), because even if the script is free, it effectively depend on non-source-code-according-to-the-interpretation-above. An example of such package is torbrowser-launcher - and an example that surprisingly seem to be in main is rustup. If your goal is to build a web front as part of an official Debian package, then you cannot do the above in main or contrib - only in non-free (which is technically not official Debian) can you stuff non-source code into a package. It does not matter to the above whether other packages are doing it already: Two wrongs don't make a right. What might matter is that I can be mistaken. If you are looking for rock-solid interpretations of the exact boundaries of Debian rules, because you want to do some cleverness close to the boundary, then I suspect that consulting a team list is the wrong place to ask: A better place is debian-devel or debian-legal, I guess. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
