[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[scl.org] Removing 'scls' from %{_sysconfdir} and %{_localstatedir}?

Latest scl-utils define the following paths if %{nfsmountable} macro is defined:

  %{_sysconfdir}    expands to /etc/opt/<vendor>/scls/<sclname>
  %{_localstatedir} expands to /var/opt/<vendor>/scls/<sclname>

(see the 'scls' part) but the rest files don't use 'scls', e.g.:

  %{_bindir}        expands to /opt/<vendor>/<sclname>

(no 'scls' in the path).

I've heard a serious critic of this *inconsistency* today from our QE -- using 'scls' under /etc/opt and /var/opt, but not in /opt. And I admit I agree with them, even though I haven't paid much attention to that inconsistency before.

This 'scls' part probably comes from the Fedora draft [1], but realize that in that draft 'scls' is also used under /opt/<vendor>.

I can't find any reasoning for this 'scls' directory, I can only assume it was used to distinguish SCL technology from other possible technologies utilizing /opt in the future.

My opinion is we don't need this distinguishing at all.

Software Collections are just a delivery mechanism, to place files into a unique structure, separated based on the *collection name*. If we don't need to separate SCLs by any 'scl' keyword on RPM packages names (i.e. we don't call collections with scl-colname, at least not now), we don't need to do it on filesystem level either.

On the other hand, if we find out in the future, that this distinguishing is necessary, we'll need to do it not only in the files paths, but also in the RPM names, so the 'scl' would need to be used in the collection name itself.. At any case, 'scls' should be removed from the paths /etc/opt/ and /var/opt/.

[1] http://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_%28draft%29


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]