Re: advisable to use installer script?
On Mon, Apr 06, 2020 at 10:49:13PM +0200, Alex Mestiashvili wrote:
> On 4/6/20 9:33 PM, Reco wrote:
> > On Mon, Apr 06, 2020 at 08:49:53PM +0200, Alex Mestiashvili wrote:
> >> Regarding Python and R modules of unknown quality. What quality?
> >
> > My question exactly. Who build it? From which source? What toolchain was
> > in use? How can I build the same in a reproduceable way? What else was
> > bundled along the way? What about upgrading and deleting a module
> > (installing is always the easiest part)?
>
> R packages and python modules as everything else packageable for Debian
> comes as source code, so how it is build is up to you and tools you use.
You don't get it. A python module may come with C source code to build a
ELF library (what they call an FFI).
The contents of the built library may differ even for two successive
builds *unless* the library is built in a very specific way.
Same goes for executables, but python modules do not do that, usually.
What's the point of having the source code if one cannot verify that the
library is built from that source?
> Even more, binary packages might be suboptimal compared to locally built
> ones.
You're using the wrong distribution then. I'd suggest something like
Gentoo, but it's dying. I don't know, LFS maybe?
> >> Debian doesn't magically make any python module better or safer.
> >
> > Yet it's known which source was used, which toolchain was there and
> > there are guarantees that the module in question does not change its
> > behaviour in the next five minutes.
>
> There is no problem to track all the above with most open source
> projects.
That's the attitude I see much these days. I could not care less about
"open source" (i.e. you can see but you cannot touch).
I care only about "free software" (as in freedom), which, specifically,
allows me to modify anything for any purpose, and do so in a meaningful
way.
First one is a popular gimmick. Second one actually gives users control.
> It's open source, nobody prevents you from checking every bit.
The best thing in Debian that I usually don't have to, for their packages.
> >> Debian just packages a python module provided by upstream and can
> >> possibly provide some additional patches and support.
> >
> > Nope, see above. Building a distribution is an engineering task more
> > complex than you seem to think it is.
>
> I guess we are talking about different things, people are asking not
> about adopting dpkg for their linux from scratch, but about installing a
> software. Most users don't care about 90% of the stuff you mentioned.
Most users do not care about many things. These include, but aren't
limited to their own security, privacy, convenience, or, btw, getting
their job done in a meaningful amount of time.
But it was always that way, and I fail to see any problem here.
But I was under the impression that we're talking about software
developers here (python and R are developers' turf). Are you saying that
developers do not care about aforementioned things?
> The only thing they care about is working software. And even not the
> software, but the goal they solve with it. Software is a tool. And they
> are not interested in the internals.
And this is why it's important to have good tools, not flawed ones.
> >> There are pros and cons for both apt and conda, but it totally depends
> >> on the use case.
> >
> > Sure. On apt's side there's unified way to install/upgrade/delete
> > anything, and on conda's side there's turning your system into
> > Slackware.
>
> I am not convinced. I don't use conda but I am pretty sure it can do all
> above and even more. It's just different and has it's own strong sides.
I've yet to see any.
> Btw, are you aware that gitlab instance for salsa.debian.org is not
> using packaged gitlab?
No, but what difference does it make in this discussion?
> There are many softwares which simply don't fit into Debian's paradigm
> of a packaging.
True. For instance, the software which the only strong side being how
fast it has been written. Or the software that's donning the hat of
"open source" while being proprietary in fact (for instance, refusing to
accept patches that re-implement already existing proprietary bits).
> But nevertheless they are useful and open source.
See above.
> >> So in general it is totally fine to use anaconda installer.
> >
> > I agree. They call the Debian the Universal OS because it can take an
> > impressive amount of such punishment from the determined user *and*
> > remain operational to a certain degree.
> > And it's hardly matters whenever the offending "tool" is called conda,
> > pip or docker.
>
> Don't forget cpan,
They take care of it with dh_cpan here.
> rvm,
Ruby's dead.
> maven
Abomination, plain and simple, and a needless reimplementation of a
wheel. But most Java shovelware falls here, so it's no surprise.
Good news are Oracle's suffocating Java, so let's leave maven for dull
enterprisey world.
Reco
Reply to: