[prototype] Debian User Repository Toolkit 0.0a release
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
info@metux.net -- +49-151-27565287
Reply to: