Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 25 Jan 2021 23:43:29 +0100
From:      Tomasz CEDRO <tomek@cedro.info>
To:        freebsd@dreamchaser.org, FreeBSD Mailing List <freebsd-questions@freebsd.org>
Subject:   Re: ruby pkg and user gem/bundle privilege mismatch
Message-ID:  <e0597c01-6442-d789-abe0-f04d77a115fb@cedro.info>
In-Reply-To: <3b533461-c2bf-2068-d965-6ca6ed2c70e5@dreamchaser.org>
References:  <9c121e6b-f6d3-0734-22e3-16a7ad6dda72@dreamchaser.org> <e58efa18-3f79-997f-a93a-7ef7e53707a3@cedro.info> <3b533461-c2bf-2068-d965-6ca6ed2c70e5@dreamchaser.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 25.01.2021 20:02, Gary Aitken wrote:
>> Summing up you should never install local packages as root to use
>> them as standard user. You should rather create your own small
>> virtual environment that you can fully control as standard user with
>> no impact to the system (or when you cannot modify system for
>> instance on the shared hosting environment).
> 
> I have lang/ruby26 installed system-wide so it is available to everyone.

There are two cases:

1. You are using system wide packages and these are used by other 
packages and programs. But you cannot modify them as standard user.

2. You are creating your own local dedicated virtual environment that 
you can control as standard user, including installing additional 
packages that are not system wide.

The later is better because you control what you have and what version 
with no impact on system wide configuration and system configuration 
does not impact you either. This is especially important when you host 
your solution on a server where you have no administrative access. This 
is very common nowadays for web application hosting that use JavaScript, 
Ruby, Python, etc. You assume some system wide starting point like basic 
interpreter and web server, then you bootstrap your own local virtual 
environment to make bigger things work on your local account. Another 
good example here is the Automated Testing and CI (Continuous 
Integration) where build/testing scripts can bootstrap several local 
dedicated environments with a bit of different setup to test different 
components version impact, test regressions, etc :-)

Best regards :-)
Tomek

-- 
CeDeROM, SQ7MHZ, https://www.tomek.cedro.info



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e0597c01-6442-d789-abe0-f04d77a115fb>