On 09.04.19 05:32, Mo Zhou wrote: Hi,
> I drafted a 0.0 alpha release[1] for the toolkit, and created a logo for > the DUPR project. From now on I'll try to add more packaging scripts > (maybe I should call them recipes) to the default collection[2]. > Packaing plans are tracked here[3], and maybe further discussion about > the DUPR (DUR, whatever.) should be redirected to a dedicated issue[4]. > And, I hope someone could put forward a better name for these prototypes > (naming issue tracked here: [6]). it seems that you're trying to package crap software. I, personally, only touching those stuff when a customer inserts lots of coins for that. And in these cases, I make it absolutely clear to them, that we can't expect quality and stability - relying on binary-only crap is always playing russian-roulette. The mentioned cuda stuff (remember that Nvidia is a very pretty hostile and fraudulent corporation) is just the tip of the iceberg - so called "professional" software in industrial world (eg. Xilinx studio, Sigasi, etc) is even more crappy. (Xilinx is also criminal - eg. *deliberately* violating the GPL). That's a kind of software, you seriously don't wanna install outside a well-confined container anyways. In some cases, I just write usual debian/rules files, or the q&d ansible way. Usually, the job is to provide whole container environments for the customer's daily work - deb packaging is just one element here, which isn't necessarily economically efficient (for those stuff, I've already given up the idea of quality, it's just about making the customer happy enough, so he inserts more coins :p). A major challenge here is retrieving the original media in a *reliable* and fully automatic way, even in the customer's often pretty weird network setups. One just cannot rely that the original media remain online - expect it to vanish over night, w/o any single notice. Therefore you also need your own local mirror, if that stuff shall come anywhere near to production use. I would be open for collaborating in maintainance of install stuff for such crapware (some of that I've already got @github), but there's a lot more to do than just yet another way to build debs. OTOH, I'm a bit reluctant to publish some fancy solution, as the vendors of those crapware - as well as their customers, who even pay for that crap - should feel the pain. That pain has be increased much higher, before anybody there even considers learning the fundamental basics of software build and deployment. (as long as they plague us with their ridiculous installers, they haven't learned a single bit). Maybe we should pick a different license here, which mandantes the customers to squeeze the vendor's balls, make them feel a lot pain ;-) (eg. the customer could tell the vendor something like "this is the last time we tolarate that, next purchases only if you provide properly long-term maintained apt repos for the distros and arch's we use). Okay, it's just a dream, but a very nice one ;-) --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
