Re: [scl.org] Idea: Software Collections Daemons Made System-wide

2017-03-22 Thread Honza Horak 

Thanks for your input, guys, really appreciated.

Honza

On 03/22/2017 03:51 PM, Davis, Daniel (NIH/NLM) [C] wrote:

Amen to this.   I shipped an appliance install base on Pungi/Anaconda, but in 
my current role, I do not have root.
I found SCL and got what we needed without us having to build it ourself.

-Original Message-
From: sclorg-boun...@redhat.com [mailto:sclorg-boun...@redhat.com] On Behalf Of 
Griffin, Wesley (Fed)
Sent: Wednesday, March 22, 2017 10:49 AM
To: Honza Horak ; sclorg@redhat.com
Subject: Re: [scl.org] Idea: Software Collections Daemons Made System-wide

My use case is for newer compilers and interpreters on development workstations.

I do not, however, manage my systems - our system administrator does that, so I 
work with him to get the SCL packages installed where necessary.

I am pretty confident that if I wanted to install an SCL package and it wrapped 
the system binary in some way he would refuse. He supports many more machines 
than just my development group and tries to maintain the same set of packages 
across all machines.

The beauty of SCL is that he can install it everywhere, but not affect anybody 
that doesn't opt-in. We have a similar setup for Intel compilers, Matlab, and 
other scientific software used in our organization.

So in that sense, adapting to a new approach would be troublesome, but only if 
it was the only approach. As long as the system binary wrappers are in 
subpackages which are optional, then I see no issues for us to continue using 
future SCL packages.

Thanks,
Wes


From: Honza Horak 
Sent: Wednesday, March 22, 2017 3:41:54 AM
To: Griffin, Wesley (Fed); sclorg@redhat.com
Subject: Re: [scl.org] Idea: Software Collections Daemons Made System-wide

I don't expect we'll do this for existing packages we provide, it's more a 
vision for new collections (e.g. mariadb 10.2 at some point).

Anyway, do you also see the same point for those upcoming collections (where 
we're not tight by keeping backward compatibility), e.g. because you're fine 
with all the SCL specifics and adapting to the new way would be troublesome?

Honza


On 03/22/2017 04:30 AM, Griffin, Wesley (Fed) wrote:

I will chime in as the "old curmudgeon" - as long as you don't break the 
existing use case, then I'm fine with any changes. The blog post says subpackages will be 
used to ensure no breakage - I just want to re-iterate that this is important and should 
not get lost if the proposal changes.

Thanks,
Wes


From: sclorg-boun...@redhat.com  on behalf
of Honza Horak 
Sent: Tuesday, March 21, 2017 11:05:26 AM
To: sclorg@redhat.com
Subject: [scl.org] Idea: Software Collections Daemons Made System-wide

This is basically a kick-off for getting more feedback for an idea
shared at
http://www.themindiseverything.eu/2017/03/software-collections-daemons-made.html.

Shortly, SCL has worked nicely for several years and people love them.
But even the beloved ones have some issues. And what we hear from
users, the issues with Software Collections concept currently are basically 
those:

* we need to use scl enable, which changes $PATH and other environment
variables, so the binaries placed in different location are visible by
the system
* scripts originally written for "normal" MySQL use full paths (like
/usr/bin/mysql) which does not work when we only have the Software
Collection installed
* Data directory, config files and log files are on different location
than it is common

The blog post tries to summarize possible solution, which I'm looking
for feedback now, ideally by replying to this mail..

TIA,
Honza

___
SCLorg mailing list
SCLorg@redhat.com
https://www.redhat.com/mailman/listinfo/sclorg

___
SCLorg mailing list
SCLorg@redhat.com
https://www.redhat.com/mailman/listinfo/sclorg




___
SCLorg mailing list
SCLorg@redhat.com
https://www.redhat.com/mailman/listinfo/sclorg

___
SCLorg mailing list
SCLorg@redhat.com
https://www.redhat.com/mailman/listinfo/sclorg




___
SCLorg mailing list
SCLorg@redhat.com
https://www.redhat.com/mailman/listinfo/sclorg

Re: [scl.org] Idea: Software Collections Daemons Made System-wide

2017-03-22 Thread Davis, Daniel (NIH/NLM) [C] 
Amen to this.   I shipped an appliance install base on Pungi/Anaconda, but in 
my current role, I do not have root.
I found SCL and got what we needed without us having to build it ourself.

-Original Message-
From: sclorg-boun...@redhat.com [mailto:sclorg-boun...@redhat.com] On Behalf Of 
Griffin, Wesley (Fed)
Sent: Wednesday, March 22, 2017 10:49 AM
To: Honza Horak ; sclorg@redhat.com
Subject: Re: [scl.org] Idea: Software Collections Daemons Made System-wide

My use case is for newer compilers and interpreters on development workstations.

I do not, however, manage my systems - our system administrator does that, so I 
work with him to get the SCL packages installed where necessary.

I am pretty confident that if I wanted to install an SCL package and it wrapped 
the system binary in some way he would refuse. He supports many more machines 
than just my development group and tries to maintain the same set of packages 
across all machines.

The beauty of SCL is that he can install it everywhere, but not affect anybody 
that doesn't opt-in. We have a similar setup for Intel compilers, Matlab, and 
other scientific software used in our organization.

So in that sense, adapting to a new approach would be troublesome, but only if 
it was the only approach. As long as the system binary wrappers are in 
subpackages which are optional, then I see no issues for us to continue using 
future SCL packages.

Thanks,
Wes


From: Honza Horak 
Sent: Wednesday, March 22, 2017 3:41:54 AM
To: Griffin, Wesley (Fed); sclorg@redhat.com
Subject: Re: [scl.org] Idea: Software Collections Daemons Made System-wide

I don't expect we'll do this for existing packages we provide, it's more a 
vision for new collections (e.g. mariadb 10.2 at some point).

Anyway, do you also see the same point for those upcoming collections (where 
we're not tight by keeping backward compatibility), e.g. because you're fine 
with all the SCL specifics and adapting to the new way would be troublesome?

Honza


On 03/22/2017 04:30 AM, Griffin, Wesley (Fed) wrote:
> I will chime in as the "old curmudgeon" - as long as you don't break the 
> existing use case, then I'm fine with any changes. The blog post says 
> subpackages will be used to ensure no breakage - I just want to re-iterate 
> that this is important and should not get lost if the proposal changes.
>
> Thanks,
> Wes
>
> 
> From: sclorg-boun...@redhat.com  on behalf 
> of Honza Horak 
> Sent: Tuesday, March 21, 2017 11:05:26 AM
> To: sclorg@redhat.com
> Subject: [scl.org] Idea: Software Collections Daemons Made System-wide
>
> This is basically a kick-off for getting more feedback for an idea 
> shared at 
> http://www.themindiseverything.eu/2017/03/software-collections-daemons-made.html.
>
> Shortly, SCL has worked nicely for several years and people love them.
> But even the beloved ones have some issues. And what we hear from 
> users, the issues with Software Collections concept currently are basically 
> those:
>
> * we need to use scl enable, which changes $PATH and other environment 
> variables, so the binaries placed in different location are visible by 
> the system
> * scripts originally written for "normal" MySQL use full paths (like
> /usr/bin/mysql) which does not work when we only have the Software 
> Collection installed
> * Data directory, config files and log files are on different location 
> than it is common
>
> The blog post tries to summarize possible solution, which I'm looking 
> for feedback now, ideally by replying to this mail..
>
> TIA,
> Honza
>
> ___
> SCLorg mailing list
> SCLorg@redhat.com
> https://www.redhat.com/mailman/listinfo/sclorg
>
> ___
> SCLorg mailing list
> SCLorg@redhat.com
> https://www.redhat.com/mailman/listinfo/sclorg
>
>

___
SCLorg mailing list
SCLorg@redhat.com
https://www.redhat.com/mailman/listinfo/sclorg

___
SCLorg mailing list
SCLorg@redhat.com
https://www.redhat.com/mailman/listinfo/sclorg

Re: [scl.org] Idea: Software Collections Daemons Made System-wide

2017-03-22 Thread Griffin, Wesley (Fed) 
My use case is for newer compilers and interpreters on development workstations.

I do not, however, manage my systems - our system administrator does that, so I 
work with him to get the SCL packages installed where necessary.

I am pretty confident that if I wanted to install an SCL package and it wrapped 
the system binary in some way he would refuse. He supports many more machines 
than just my development group and tries to maintain the same set of packages 
across all machines.

The beauty of SCL is that he can install it everywhere, but not affect anybody 
that doesn't opt-in. We have a similar setup for Intel compilers, Matlab, and 
other scientific software used in our organization.

So in that sense, adapting to a new approach would be troublesome, but only if 
it was the only approach. As long as the system binary wrappers are in 
subpackages which are optional, then I see no issues for us to continue using 
future SCL packages.

Thanks,
Wes


From: Honza Horak 
Sent: Wednesday, March 22, 2017 3:41:54 AM
To: Griffin, Wesley (Fed); sclorg@redhat.com
Subject: Re: [scl.org] Idea: Software Collections Daemons Made System-wide

I don't expect we'll do this for existing packages we provide, it's more
a vision for new collections (e.g. mariadb 10.2 at some point).

Anyway, do you also see the same point for those upcoming collections
(where we're not tight by keeping backward compatibility), e.g. because
you're fine with all the SCL specifics and adapting to the new way would
be troublesome?

Honza


On 03/22/2017 04:30 AM, Griffin, Wesley (Fed) wrote:
> I will chime in as the "old curmudgeon" - as long as you don't break the 
> existing use case, then I'm fine with any changes. The blog post says 
> subpackages will be used to ensure no breakage - I just want to re-iterate 
> that this is important and should not get lost if the proposal changes.
>
> Thanks,
> Wes
>
> 
> From: sclorg-boun...@redhat.com  on behalf of 
> Honza Horak 
> Sent: Tuesday, March 21, 2017 11:05:26 AM
> To: sclorg@redhat.com
> Subject: [scl.org] Idea: Software Collections Daemons Made System-wide
>
> This is basically a kick-off for getting more feedback for an idea
> shared at
> http://www.themindiseverything.eu/2017/03/software-collections-daemons-made.html.
>
> Shortly, SCL has worked nicely for several years and people love them.
> But even the beloved ones have some issues. And what we hear from users,
> the issues with Software Collections concept currently are basically those:
>
> * we need to use scl enable, which changes $PATH and other environment
> variables, so the binaries placed in different location are visible by
> the system
> * scripts originally written for "normal" MySQL use full paths (like
> /usr/bin/mysql) which does not work when we only have the Software
> Collection installed
> * Data directory, config files and log files are on different location
> than it is common
>
> The blog post tries to summarize possible solution, which I'm looking
> for feedback now, ideally by replying to this mail..
>
> TIA,
> Honza
>
> ___
> SCLorg mailing list
> SCLorg@redhat.com
> https://www.redhat.com/mailman/listinfo/sclorg
>
> ___
> SCLorg mailing list
> SCLorg@redhat.com
> https://www.redhat.com/mailman/listinfo/sclorg
>
>

___
SCLorg mailing list
SCLorg@redhat.com
https://www.redhat.com/mailman/listinfo/sclorg

Re: [scl.org] Idea: Software Collections Daemons Made System-wide

2017-03-22 Thread Remi Collet 
Le 21/03/2017 à 16:05, Honza Horak a écrit :
> This is basically a kick-off for getting more feedback for an idea
> shared at
> http://www.themindiseverything.eu/2017/03/software-collections-daemons-made.html.


Having an -system-wide package, providing a set of symlinks
looks like a nice idea

This can become hard to create, when there is multiple packages
providing commands / service: e.g

php-cli   => /usr/bin/php
php-devel => /usr/bin/phpize (and some others)
php-pear  => /usr/bin/pear   (and some others)
php-fpm   => /usr/bin/php-fpm and php-fpm.service
php-pecl-xdebug => /usr/bin/debugclient

Another possible tricky bit is the socket used

For now php-fpm listen on a network socket (localhost:9000) in base
system and SCL, so the SCL provided service can really simply replace
the system default one (like for databases).

But, if we switch to UDS in the future this will become a bit more
tricky (each SCL listen on a different UDS), symlink "could" work (this
need to be checked).


BTW a bit more simple for PHP which doesn't need any wrapper ;)
(a simple symlink to the SCL binary is enough)



Just few other comments which may help
(a bit out-of-topic with your proposal, but related to SCL usability)


- have you tried the service alias ? (exists in both SysV and systemd)


- moving  man page to base system

As it could be consider a bit strange to have to enable the collection
to read the documentation explaining how to enable it...


- providing the module configuration file

Because "scl enable" is not the best user friendly command, and may
raise PATH overflow when used a lot, "module load" seems better (at
least to me)

This is default with scl-utils v2, but works perfectly with scl-utils
v1, just dropping the file in the right place
(/usr/share/Modules/modulefiles/)





Remi.

___
SCLorg mailing list
SCLorg@redhat.com
https://www.redhat.com/mailman/listinfo/sclorg

Re: [scl.org] Idea: Software Collections Daemons Made System-wide

2017-03-22 Thread Nick Coghlan 
On Wed, Mar 22, 2017 at 1:05 AM, Honza Horak  wrote:
> This is basically a kick-off for getting more feedback for an idea shared at
> http://www.themindiseverything.eu/2017/03/software-collections-daemons-made.html.
>
> Shortly, SCL has worked nicely for several years and people love them. But
> even the beloved ones have some issues. And what we hear from users, the
> issues with Software Collections concept currently are basically those:
>
> * we need to use scl enable, which changes $PATH and other environment
> variables, so the binaries placed in different location are visible by the
> system
> * scripts originally written for "normal" MySQL use full paths (like
> /usr/bin/mysql) which does not work when we only have the Software
> Collection installed
> * Data directory, config files and log files are on different location than
> it is common
>
> The blog post tries to summarize possible solution, which I'm looking for
> feedback now, ideally by replying to this mail..

If you change the exec line in the wrapper script to be:

exec -a $0 `basename "$0"` "$@"

I believe this may actually also deal with the Python sys.executable
and hence setuptools and pipsi compatibility problems that I raised in
https://bugzilla.redhat.com/show_bug.cgi?id=1385471

Otherwise sys.executable will still be set to the unwrapped binary,
and any generated shebang lines would refer to that rather than the
wrapper script.

Cheers,
Nick.

-- 
Nick Coghlan
Red Hat Platform Engineering, Brisbane

___
SCLorg mailing list
SCLorg@redhat.com
https://www.redhat.com/mailman/listinfo/sclorg