[prev in list] [next in list] [prev in thread] [next in thread] 

List:       nix-dev
Subject:    Re: [Nix-dev] Two declarative ways to install a package?
From:       "Guillaume Maudoux (Layus)" <layus.on () gmail ! com>
Date:       2016-08-12 16:26:09
Message-ID: 3AB9F167-28EF-4200-AD1E-CEEA6E7CDF0A () gmail ! com
[Download RAW message or body]



Le 12 août 2016 18:02:49 UTC+02:00, Arnold Krille <arnold@arnoldarts.de> a écrit :
> On Fri, 12 Aug 2016 16:15:46 +0200 "Guillaume Maudoux (Layus)"
> <layus.on@gmail.com> wrote:
> > I would rather see it as a convenience.
> > The package is in your store anyway, so better make it available in
> > user shells.
> 
> No, only expose what is needed or wanted explicit (explicit is better
> then implicit;-)). Just because I want mpd to run on my machine,
> doesn't mean I want every user to run its own mpd (and wonder why the
> default-port is already in use). For example.
> 

I guess m'y use cases are only single-user machines, where the difference between \
user and system is sometimes fuzzy.

> > With mysql for example, having the mysql command in your path is not
> > strictly necessary, but it would be really annoying not to have it.
> > Forcing users to install it in their own environments could even lead
> > to version mismatches.
> 
> This largely depends on the package, doesn't it?
> 
> For the mysql-service to expose the mysql-commandline tool is a nice
> convenience, at the same time exposing the mysqld binary is needless
> and allows other apps to use that binary without actually depending on
> it. It also allows foes to use it directly from your environment
> without dealing specially with nix.
> 
> For the nginx-package to expose the nginx-daemon binary to your
> environment isa bit useless for the same reasons explained with mysqld
> exposed. But are there user-tools for nginx that should be exposed?
> 
> Maybe it would be better if there was a mysql and a mysql-server
> package and the mysql-service would use the mysql-server itself and
> expose the mysql commandline to the environment without exposing the
> server binary?
> 
> > If exposing a package from its service happens to be annoying (for
> > whatever reason),
> > may I suggest suggest to pull-request an opt-out option for it ?
> 
> For security and sanity reason, it should be opt-in.

I think your point ils valid. But an option is not so useful in this case. Adding the \
package to the environment directly may even be simpler than enabling the option.

Oh btw, What would you think of a global opt-in option ? Like noXLibs ?

> 
> - Arnold
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev

_______________________________________________
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


[prev in list] [next in list] [prev in thread] [next in thread]