Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #221004 > unrolled thread

advisable to use installer script?

Back to article view | Back to linux.debian.user

Contents

  advisable to use installer script? Anil F Duggirala <anilduggirala@fastmail.fm> - 2020-04-06 16:50 +0200
    Re: advisable to use installer script? Reco <recoverym4n@enotuniq.net> - 2020-04-06 17:50 +0200
      Re: advisable to use installer script? Anil F Duggirala <anilduggirala@fastmail.fm> - 2020-04-06 18:50 +0200
        Re: advisable to use installer script? Alex Mestiashvili <amestia@rsh2.donotuse.de> - 2020-04-06 21:00 +0200
          Re: advisable to use installer script? Greg Wooledge <wooledg@eeg.ccf.org> - 2020-04-06 21:00 +0200
            Re: advisable to use installer script? Celejar <celejar@gmail.com> - 2020-05-08 17:40 +0200
              Re: advisable to use installer script? Andrei POPESCU <andreimpopescu@gmail.com> - 2020-05-09 07:10 +0200
                Re: advisable to use installer script? Celejar <celejar@gmail.com> - 2020-05-10 04:10 +0200
          Re: advisable to use installer script? Reco <recoverym4n@enotuniq.net> - 2020-04-06 21:40 +0200
            Re: advisable to use installer script? Alex Mestiashvili <amestia@rsh2.donotuse.de> - 2020-04-06 22:50 +0200
              Re: advisable to use installer script? Reco <recoverym4n@enotuniq.net> - 2020-04-06 23:50 +0200
                Re: advisable to use installer script? Celejar <celejar@gmail.com> - 2020-05-08 17:40 +0200
              Re: advisable to use installer script? Andrei POPESCU <andreimpopescu@gmail.com> - 2020-04-07 10:20 +0200
                Re: advisable to use installer script? <tomas@tuxteam.de> - 2020-04-07 10:40 +0200
          Re: advisable to use installer script? Andrei POPESCU <andreimpopescu@gmail.com> - 2020-04-07 10:10 +0200

#221004 — advisable to use installer script?

hello,
I am looking to install Anaconda in my machine, Debian Buster. There
suggested installation method is using an installer that is downloaded
from their site. Is it advisable to install software in this manner?
Can anyone give a broad idea of what this install script does? Does
make changes to my system files?

thank you,

[toc] | [next] | [standalone]

#221008

	Hi.

On Mon, Apr 06, 2020 at 09:43:48AM -0500, Anil F Duggirala wrote:
> hello,
> I am looking to install Anaconda in my machine, Debian Buster. There
> suggested installation method is using an installer that is downloaded
> from their site.

I'm assuming it's this one: https://www.anaconda.com/distribution/#linux
Somehow I find it unlikely that you want to install RHEL's installer
(called anaconda too) on Debian.


> Is it advisable to install software in this manner?

No more or no less than running arbitrary binary from the nearest warez
dump. I.e. there are few cases when you can probably get away with it,
but you're risking doing it.


> Can anyone give a broad idea of what this install script does?

Extracts a HUEG tar.bz2 archive full of (presumably) Python and R
modules of unknown quality. Why would anyone (short of Windoze user)
willingly use this anaconda given the existence of pip and CRAN is
beyond me.
In Debian we have apt for this, and I kindly suggest you to consider
using it instead.


> Does make changes to my system files?

Unlikely, script *seems* to be limited to user-writable $PREFIX.
A quick look at the script contents haven't revealed anything fishy.
But I haven't run it, and do not intend to.

At most you're risking running some cryptominer (with user privileges)
or stealing/damaging the contents of your $HOME. Just do not run the
thing as root.

Reco

[toc] | [prev] | [next] | [standalone]

#221009

> I'm assuming it's this one: 
> https://www.anaconda.com/distribution/#linux

Thats the one.


> > Can anyone give a broad idea of what this install script does?
> 
> Extracts a HUEG tar.bz2 archive full of (presumably) Python and R
> modules of unknown quality. Why would anyone (short of Windoze user)
> willingly use this anaconda given the existence of pip and CRAN is
> beyond me.
> In Debian we have apt for this, and I kindly suggest you to consider
> using it instead.
> 
Thank you Reco. I will use either apt or pip. I am looking to use scipy
basically, that's all I need, Anaconda comes with bunch of things I
don't need. I have noticed that modules are a bit outdated in apt
however, I asked a separate question regarding that.
I am glad not to be a Windoze user. And now I am also glad you are not
a Windoze user.
thank you.

[toc] | [prev] | [next] | [standalone]

#221017

On 4/6/20 6:44 PM, Anil F Duggirala wrote:
>> I'm assuming it's this one: 
>> https://www.anaconda.com/distribution/#linux
> 
> Thats the one.
> 
> 
>>> Can anyone give a broad idea of what this install script does?
>>
>> Extracts a HUEG tar.bz2 archive full of (presumably) Python and R
>> modules of unknown quality. Why would anyone (short of Windoze user)
>> willingly use this anaconda given the existence of pip and CRAN is
>> beyond me.
>> In Debian we have apt for this, and I kindly suggest you to consider
>> using it instead.
>>
> Thank you Reco. I will use either apt or pip. I am looking to use scipy
> basically, that's all I need, Anaconda comes with bunch of things I
> don't need. I have noticed that modules are a bit outdated in apt
> however, I asked a separate question regarding that.
> I am glad not to be a Windoze user. And now I am also glad you are not
> a Windoze user.
> thank you.
> 
> 

Anaconda/conda/miniconda have very big advantages over what Debian
offers - rootless installation and bigger? variety of applications.
I don't use it myself, but in many places where people don't have admin
privileges on workstations or computing clusters, conda is very useful.
There are many scientific pipelines completely based on conda, just
because conda applications can be installed in home directory or are
simply available without messing up with install from sources.

Regarding Python and R modules of unknown quality. What quality? Debian
doesn't magically make any python module better or safer. Debian just
packages a python module provided by upstream and can possibly provide
some additional patches and support.

There are pros and cons for both apt and conda, but it totally depends
on the use case.

So in general it is totally fine to use anaconda installer.

[toc] | [prev] | [next] | [standalone]

#221018

On Mon, Apr 06, 2020 at 08:49:53PM +0200, Alex Mestiashvili wrote:
> Regarding Python and R modules of unknown quality. What quality? Debian
> doesn't magically make any python module better or safer. Debian just
> packages a python module provided by upstream and can possibly provide
> some additional patches and support.

The main thing you get from Debian is stability -- a given package is
tested quite extensively, at least in theory.  If there are bugs or
flaws, they get patched, or mitigated in some way.

Of course the extent of this stability testing depends on the popularity
of the package, so a module that only a hundred people ever use might not
receive as much quality assurance/improvement as, say, xterm does.

[toc] | [prev] | [next] | [standalone]

#222296

On Mon, 6 Apr 2020 14:53:00 -0400
Greg Wooledge <wooledg@eeg.ccf.org> wrote:

> On Mon, Apr 06, 2020 at 08:49:53PM +0200, Alex Mestiashvili wrote:
> > Regarding Python and R modules of unknown quality. What quality? Debian
> > doesn't magically make any python module better or safer. Debian just
> > packages a python module provided by upstream and can possibly provide
> > some additional patches and support.
> 
> The main thing you get from Debian is stability -- a given package is
> tested quite extensively, at least in theory.  If there are bugs or
> flaws, they get patched, or mitigated in some way.

Very much "in theory". Numerous bugs in the BTS are simply ignored. And
why would you assume that they (always? usually?) get patched? Insofar
as the bug is not Debian specific, it often (at best) just gets
forwarded to upstream, who react to it as they please. I don't think
the Debian maintainers will generally fix broken code on their own.

Debian does guarantee that really bad things won't happen - if the bug
severity is high enough, the package will get booted from Debian /
won't make it into Stable, or mitigated in some other way. But simple
stability and functionality bugs often stay there for years.

Of course, I have great admiration and gratitude for the incredible
work that makes Debian what it is. I'm just noting that at least for
non-RC and security related bugs, the system does not work nearly as
well as it should in theory ;)

> Of course the extent of this stability testing depends on the popularity
> of the package, so a module that only a hundred people ever use might not
> receive as much quality assurance/improvement as, say, xterm does.

Indeed. It's just not clear to me that a typical package in Debian will
have fewer bugs than the same software downloaded straight from
upstream.

Celejar

[toc] | [prev] | [next] | [standalone]

#222307

[Multipart message — attachments visible in raw view] — view raw

On Vi, 08 mai 20, 11:31:13, Celejar wrote:
> 
> Indeed. It's just not clear to me that a typical package in Debian will
> have fewer bugs than the same software downloaded straight from
> upstream.

The main "selling" point for Debian is that the software is properly 
integrated with the rest of the system and easy to upgrade, even between 
releases.

Additionally most packages are built for all architectures, which helps 
uncover some interesting bugs that upstream wouldn't find otherwise.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#222320

On Sat, 9 May 2020 08:00:54 +0300
Andrei POPESCU <andreimpopescu@gmail.com> wrote:

> On Vi, 08 mai 20, 11:31:13, Celejar wrote:
> > 
> > Indeed. It's just not clear to me that a typical package in Debian will
> > have fewer bugs than the same software downloaded straight from
> > upstream.
> 
> The main "selling" point for Debian is that the software is properly 
> integrated with the rest of the system and easy to upgrade, even between 
> releases.

Oh, absolutely - that's one of the things I love about our OS. I
was referring to general bugs in the software itself, though, and not
those having to do with upgradeability or integration with other
packages.

Celejar

[toc] | [prev] | [next] | [standalone]

#221023

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)?


> 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.
Oh, and there are distribution-specific patches which *do* make packages
better and safer, python included. And, what's most important here -
compatible with *other* 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.


> 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.


> 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.

Reco

[toc] | [prev] | [next] | [standalone]

#221025

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.
Even more, binary packages might be suboptimal compared to locally built
ones.

> 
> 
>> 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. It's open source, nobody prevents you from checking every bit.

> Oh, and there are distribution-specific patches which *do* make packages
> better and safer, python included. And, what's most important here -
> compatible with *other* packages.

That's the different thing and that's one of the strong sides of Debian,
totally agree here.

> 
> 
>> 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.
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.

> 
> 
>> 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.

Btw, are you aware that gitlab instance for salsa.debian.org is not
using packaged gitlab?
There are many softwares which simply don't fit into Debian's paradigm
of a packaging. But nevertheless they are useful and open source.

> 
> 
>> 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, rvm, maven and so on. They all have their niche as
well as apt.

> 
> Reco
> 

Best,
Alex

[toc] | [prev] | [next] | [standalone]

#221029

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

[toc] | [prev] | [next] | [standalone]

#222297

On Tue, 7 Apr 2020 00:43:35 +0300
Reco <recoverym4n@enotuniq.net> wrote:

...

> 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.

You exaggerate. Even if OSS on its own doesn't give users control
(which is indeed a real problem), it's nevertheless much more than a
popular gimmick: we can see exactly what the software is doing, check
whether it's phoning home, etc. And even if most of us aren't checking
most or any of the software that we use, the odds of something bad
being in there are surely much lower than with closed source, since
someone will likely find it if it's a reasonably popular piece of
software.

Celejar

[toc] | [prev] | [next] | [standalone]

#221049

[Multipart message — attachments visible in raw view] — view raw

On Lu, 06 apr 20, 22:49:13, Alex Mestiashvili wrote:
> 
> 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.
> Even more, binary packages might be suboptimal compared to locally built
> ones.
 
In most cases any optimization gains are offset by the maintenance 
burden, e.g. you have to keep track of security updates, rebuild the 
package, etc.

In the meantime package users just 'apt update && apt upgrade' (or 
enable unattended-upgrades) and get on with their work / life :)
 
> Btw, are you aware that gitlab instance for salsa.debian.org is not
> using packaged gitlab?
> There are many softwares which simply don't fit into Debian's paradigm
> of a packaging. But nevertheless they are useful and open source.

As far as I understand Gitlab is very complex, depends on (lots of?) 
other software that is also not packaged and doesn't have a long term 
support branch. All of these make it very difficult to create the 
package *and* maintain it in a stable release.

Hopefully at some point the upstream maintainers will adopt the long 
term support release model, as many other projects have done (e.g. 
Firefox).

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#221051

[Multipart message — attachments visible in raw view] — view raw

On Tue, Apr 07, 2020 at 11:19:27AM +0300, Andrei POPESCU wrote:
> On Lu, 06 apr 20, 22:49:13, Alex Mestiashvili wrote:
> > 
> > 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.
> > Even more, binary packages might be suboptimal compared to locally built
> > ones.
>  
> In most cases any optimization gains are offset by the maintenance 
> burden, e.g. you have to keep track of security updates, rebuild the 
> package, etc.

Exactly. There are those packages I care deeply about, so much so that
I follow development news. Those I compile off-repository, usually at
the bleeding edge; I keep whatever build infrastructure it takes well
oiled (because I do that often).

But I can't "care deeply" about each of the ~2k packages delving in
my box. I wouldn't have the bandwidth for that.

Thus, there's that other 99.95% (yeah, this statistic is probably made
up) infrastructure, which I know very little about, and which Just
Works (TM) thanks to the dedication of Debian packagers. They do an
outstanding job, and I'm infinitely thankful to them.

Thing is, "those packages you care deeply about" are different ones
from person to person. To me, it's Emacs and Guile, to you it's Apache
or LibreOffice or Lua and Enigma.

The cool thing about a distribution like Debian is that it sets
a baseline of "reasonable" versions, offering a path to deliver the
achievement of specialists to all the others. It's the glue holding
together all those brilliant gems into a coherent whole. Smaug,
if you like :)

For that, I say "THANK YOU" to all those maintainers.

Cheers
-- tomás

[toc] | [prev] | [next] | [standalone]

#221048

[Multipart message — attachments visible in raw view] — view raw

On Lu, 06 apr 20, 20:49:53, Alex Mestiashvili wrote:
> 
> Regarding Python and R modules of unknown quality. What quality? Debian
> doesn't magically make any python module better or safer. Debian just
> packages a python module provided by upstream and can possibly provide
> some additional patches and support.

Debian Developers can also choose to not package a low quality module 
(though probably many more are not packaged simply due to lack of 
manpower / need / interest / etc.).

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web