Skip to content

Perlbrew has gotten worse for shared installations #85

avar opened this Issue May 15, 2011 · 7 comments

3 participants

avar commented May 15, 2011

My use case for perlbrew is that for almost everything I'm replacing the system perl on my server with a perlbrew maintained installation.

I install modules & perlbrew versions under the user v-perlbrew hosted in /home/v-perlbrew, but other users (e.g. cronjobs etc) use that perl.

It used to be that I could just add something like this to my cronjobs:


But now that perlbrew seems to no longer create the /home/v-perlbrew/perl5/perlbrew/bin symlink I have to now maintain it myself, e.g.:

sudo rm -rfv /home/v-perlbrew/perl5/perlbrew/bin
sudo ln -sf /home/v-perlbrew/perl5/perlbrew/perls/perl-5.14.0/bin /home/v-perlbrew/perl5/perlbrew/bin

And furthermore, users that are not cronjobs had to have this in their .bashrc:

test -f ~v-perlbrew/perl5/perlbrew/etc/bashrc && source ~v-perlbrew/perl5/perlbrew/etc/bashrc

Changed to:

test -f ~v-perlbrew/perl5/perlbrew/etc/bashrc && HOME=/home/v-perlbrew source ~v-perlbrew/perl5/perlbrew/etc/bashrc

Since the ~/perl5/perlbrew/etc/bashrc now makes the assumption (which it didn't before) that ~/perl5 can be found under $HOME, as opposed to having the full paths hardcoded in.

Proposed fixes to make this workflow work:

  • Instead of looking under $HOME look under a path relative to the bashrc being sourced
  • Provide an option to maintain the "bin" symlink again, or put it back in by default.


gugod commented May 16, 2011

I do not consider the lack of symilnks under PERLBREW_ROOT/bin to be a "worse" idea. However, I do recognize this issue as the lack of sufficient documentation for migration from older versions perlbrew.

Perlbrew was not designed with shared installation in mind at all in the beginning, and the use of 'current' symlink is just global, and not a really good idea for a shared installation.

My goal for a good shared installations is to let multiple users can all run switch and use command just fine (require read and/or executable file access) , while only some of them can run install and clean (require read + write file access). perlbrew 0.20 achieved this goal -- it was not backward-compatible though.

In your case, you should be able to add these two lines to make everything works:

export PERLBREW_ROOT=/home/v-perlbrew/perl5/perlbrew
source $PERLBREW_ROOT/etc/bashrc

The $PERLBREW_ROOT/etc/bashrc stores personal settings of (the state after a switch command) to ~/.perlbrew/init, at this point it does assume a $HOME variable to be there. To run your program from crontab, I suggest you to either hard code the shebang, or hard code the PATH in crontab:


You might consider it troublesome, but one tiny benefit is: you (or other admin) can know the perl version right there in the crontab.

Due to the massive features introduce since 0.13, I need to spend more time to do documentation work in the next few releases. I plan to put full documentations on the website, and only put some synopsis / cheat-sheet with URLs to full docs in POD.

avar commented May 16, 2011

I mean that this specific use case has gotten worse, I'm sure you have
some future plans, but they seem to have made my specific use case a
lot more work for me, when it seems that there's nothing mutually
exclusive about them. Both could optionally be provided.

Anyway, the trick you suggested doesn't work:

$ sudo -s -H
w:~# which perl
w:~# export PERLBREW_ROOT=/home/v-perlbrew/perl5/perlbrew
w:~# source $PERLBREW_ROOT/etc/bashrc
w:~# perl -v

This is perl, v5.10.1 (*) built for x86_64-linux-gnu-thread-multi
(with 53 registered patches, see perl -V for more detail)

w:~# export HOME=/home/v-perlbrew
w:/root# source $PERLBREW_ROOT/etc/bashrc
w:/root# perl -v

This is perl 5, version 14, subversion 0 (v5.14.0) built for x86_64-linux


Perhaps because I haven't done perlbrew init as root. But my point
is really that I never had to do that before.

> Perlbrew was not designed with shared installation in mind at all in
> the beginning, and the use of 'current' symlink is just global, and
> not a really good idea for a shared installation.

It's become clear to me that it wasn't, since this installation method
has been broken a few times in the past, but it's also a very useful
use case IMO.

I don't agree that using perlbrew in this way is a bad idea. My
/usr/bin/perl is a shared installation, in that if I upgrade it
everything on the system will use the same perl.

That's what I've been using perlbrew for. Once I've set relevant paths
once I can do perlbrew switch as the v-perlbrew user, and
everything on the system upgrades from say 5.12 to 5.14. Having to
start changing /home/v-perlbrew/perl5/perls/perl-5.14.0/bin to
/home/v-perlbrew/perl5/perls/perl-5.14.1/bin everywhere is just busy
work for me that I didn't need to deal with before.

So the symlink management is very useful for that, and could be
supported alongside the current facility. I'd be happy to help come up
with a patch for that, but I wanted to discuss things with you first.

Perhaps something like:

perlbrew group create system
perlbrew group set system perl-5.14.1

Which'll create a /home/v-perlbrew/perl5/perls/groups/system/bin
symlink which everyone on the system can use, but users who want their
own "perlbrew switch" can have a config file in their ~/..


I, too, have wondered about this.
I was considering using perlbrew in a detached environment...
I have a number of unmanned machines that run various tasks in the background all day long.
I'm not sure if prelbrew is ideal for a non-interactive environment (with most commands being run by cron).

I think the "group" idea could be a good one...
It's good that perlbrew can be used without symlinks (to allow simultaneous usage of multiple perls)
but it would be really nice if that feature was also available (to allow a reliable path to a named perl).

Yes, aliases could be used to name perls, but it would be nice to be able to rename perls
so that you could create perl-5.14.0 --as mainperl
and then when 5.14.1 comes out, install it, configure it, install the modules you need, test,
and then rename it to "mainperl"
so that you don't break any cronjobs while you're testing/installing a possible replacement perl.

gugod commented May 22, 2011

I've been thinking about this issue since the decision for it is
likely to deeply effect all future implementation.

perlbrew was never designed to upgrade a given installation in-place,
and it probably should never go that way. People who has the knowledge
to upgrade a perl installation does not need helps from perlbrew, and
the effort would be tremendously high to implements a simple,
transparent 'update' command. That should not be done.

On the other hand, I'm convinced that it is a good scenario that @avar
is using the current symlink as the single point of entry for all
his programs, and I'd like to keep perlbrew simple enough for him so
he does not have to change the shebang of all his programs when he
decides to upgrade perl. That is the sole reason why people use
perlbrew -- to upgrade his perl installation, and still be able to
rollback if messed up. An retreat-able all in.

As a result of thinking, I'd like to propose the 'alias'
command, which create aliases for existing installations:

# essentially ln -s perl-5.14.0 current.
#     should fail if 'current' already exists.
perlbrew alias perl-5.14.0 current

# -d for delete
perlbrew alias -d current

# -r for rename
perlbrew alias -r current main

# -f for force override
perlbrew alias -f perl-5.14.0 current

This alias command should be done by symlinks, instead of other
config-based implementations. With this, the 'current' symlink
is no longer special, and yet managable with perlbrew.

avar commented May 22, 2011

That sounds good, as far as I can tell that would solve my use case, by maintaining a symlink that I maintain manually now.

gugod commented May 23, 2011

For the record, should be considered resolved once the alias command is implemented.

gugod commented May 25, 2011

alias command is implemented in the develop branch as described in this wiki page

The syntax in slightly different then the original proposal here.

@gugod gugod closed this May 25, 2011
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.