[scl.org] scl register script

[Honza Horak]

Another thing that would deserve some best practice documented is where 
to store the files we want to work with in the register script. This is 
just a laud thinking about the location for such files, which should be 
also standardized and documented as a best practice after reaching some 
agreement.

My proposal is to include them under /opt/rh/$SCLNAME/register-content 
and use path of the resulting location under this directory. An example 
for e.g. mariadb100 I have on my mind is the following:

* having %nfsmountable macro defined, %_sysconfdif will expand to 
/etc/opt/rh/scls/mariadb100 during RPM build

* my.cnf will then be installed into /etc/opt/rh/scls/mariadb100/my.cnf

* when mounting /opt, my.cnf, init script or systemd file won't be 
available on NFS client, but we'd need it for the register script

* these files have a copy under /opt/rh/mariadb100/register-content to 
have them available on the NFS client, specifically:
   /opt/rh/mariadb100/register-content/etc/opt/rh/scls/mariadb100/my.cnf
 
/opt/rh/mariadb100/register-content/usr/lib/systemd/system/mariadb100-mariadb.service

* the register script for mariadb100-mariadb-server just gets the files 
from /opt/rh/mariadb100/register-content and places them under their 
desired location:
   /etc/opt/rh/scls/mariadb100/my.cnf
   /usr/lib/systemd/system/mariadb100-mariadb.service

Does it sound fine?

Honza

On 01/08/2015 05:40 PM, Honza Horak wrote:
> Moving this topic to sclorg at redhat.com since this is an example of a
> topic I'd like to see discussed there in public. It is related to the
> 'scl register' command, which is a scl-utils feature already available
> in [1]. Please, continue on sclorg at redhat.com ML.
>
> As for the idea, I like it as Jan proposed it and if nobody has
> objections we'll use that for new databases packages as well.
>
> As soon as we reach some conclusion here we should document it in the
> Guide [2] and maybe even mention it as good practice in the scl-utils
> doc/man/wherever register is documented?
>
> [1] https://github.com/sclorg/scl-utils
> [2] https://www.softwarecollections.org/en/docs/guide/
>
> Honza
>
>
> -------- Forwarded Message --------
> Subject: scl register script
> Date: Thu, 08 Jan 2015 13:55:41 +0100
> From: Jan Kaluža <jkaluza at redhat.com>
>
> Hi,
>
> I was thinking about "scl register" script (/opt/rh/foo/register). This
> script is called when SCL is registered (as result of "scl register foo"
> command).
>
> There can be just single "register" script per collection. I think it
> would be better to have a directory (let's call it "register.d") where
> all packages in the collection could put their register scripts and the
> main register script (the one included in meta-package) would just call
> each script in this directory.
>
> This would handle following situations:
>
> - If we add new package/directory/file which has to be handled by the
> register script, we don't have to change the register script in the
> meta-package and rebuild it, because the responsible register script
> would be part of the updated package.
>
> - If we have for example httpd24 SCL, we want to copy httpd
> configuration into /etc/opt in the register script, but we want to do
> that *only* when httpd24-httpd package is installed.
>
> So to sum it up, I'm proposing following structure for the
> register/unregister scripts:
>
> /opt/rh/foo/register - owned by "foo", calls scripts in "register.d"
> /opt/rh/foo/register.d/foo-bar - owned by foo-bar, registers foo-bar
> subpackage of foo SCL.
>
> /opt/rh/foo/unregister - owned by "foo", calls scripts in "unregister.d"
> /opt/rh/foo/unregister.d/foo-bar - owned by foo-bar, unregisters foo-bar
> subpackage of foo SCL.
>
> Regards,
> Jan Kaluza
>
>
>
> _______________________________________________
> SCLorg mailing list
> SCLorg at redhat.com
> https://www.redhat.com/mailman/listinfo/sclorg