| Message ID | 20190924140319.11303-3-olaf@aepfle.de (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | tools, doc and stubdom fixes | expand |
Olaf Hering writes ("[PATCH RESEND v1 2/8] tools: move scripts from etc to libexec"):
> In the near future all fresh installations will have an empty /etc.
Err, no ?
Ian.
Am Tue, 24 Sep 2019 15:09:58 +0100
schrieb Ian Jackson <ian.jackson@citrix.com>:
> Err, no ?
It will happen for sure:
https://github.com/thkukuk/atomic-updates_and_etc/blob/master/README.md
https://en.opensuse.org/openSUSE:Packaging_UsrEtc
Olaf
Ian Jackson writes ("Re: [PATCH RESEND v1 2/8] tools: move scripts from etc to libexec"):
> Olaf Hering writes ("[PATCH RESEND v1 2/8] tools: move scripts from etc to libexec"):
> > In the near future all fresh installations will have an empty /etc.
>
> Err, no ?
More constructively:
I think the ability of the admin to edit these scripts is important
and I have used it myself in the past. With my Debian Xen maintainer
hat on I have no intention of moving these files out of /etc.
If the maintainer of Xen in some other distro wishes to put these
files in /usr/lib and consequently make them harder to edit then
(1) my advice as Xen upstream tools maintainer is that this would be a
bad idea (2) if that maintainer wants to persist with this then they
should do this in the packages for their distro.
In support of (2), I would welcome patches that make it easier for a
distro maintainer to make these kind of choices.
Right now my view is that I do not think it would be appropriate to
change the upstream default, regardless of the installation target
operating system, but I might be open to argument on that for specific
target operating systems if the appropriate distro maintainers were to
make a case.
I hope this helps.
Thanks,
Ian.
Am Tue, 24 Sep 2019 15:17:43 +0100
schrieb Ian Jackson <ian.jackson@citrix.com>:
> I think the ability of the admin to edit these scripts is important and I have used it myself in the past.
Since they are scripts, they can be edited in any location. To me it is not clear what the case would be to diverge from the vendor provided variant.
IMO these are part of the Xen tools, there is nothing to configure in these scripts. If for whatever reason the local admin must run his own variant, at least for disk= and vif= the location can be changed with 'script='.
I'm sure they are in /etc because in the early days of Xen there was a hope the local admin would do all the work to connect backends and frontends in a way he likes. I think this is not true since more than a decade, the scripts are always tied to the tools version. The API is now mature since a while, there are very few changes in the past years.
A configure knob could be added to set XEN_SCRIPT_DIR at build time, if there is really a usecase for such knob.
Olaf
Am Tue, 24 Sep 2019 15:17:43 +0100
schrieb Ian Jackson <ian.jackson@citrix.com>:
> I might be open to argument on that for specific target operating systems if the appropriate distro maintainers were to make a case.
I provided reasons why the current default is not appropriate, and the change should be applied.
Did you come up with a reason why the provided reasons are incorrect?
Olaf
Olaf Hering writes ("Re: [PATCH RESEND v1 2/8] tools: move scripts from etc to libexec"):
> Am Tue, 24 Sep 2019 15:17:43 +0100
> schrieb Ian Jackson <ian.jackson@citrix.com>:
> > I think the ability of the admin to edit these scripts is important and I have used it myself in the past.
>
> Since they are scripts, they can be edited in any location. To me it is not clear what the case would be to diverge from the vendor provided variant.
Editing files in /usr is not really a good idea. They will be
overwritten by eg security updates.
> IMO these are part of the Xen tools, there is nothing to configure in these scripts. If for whatever reason the local admin must run his own variant, at least for disk= and vif= the location can be changed with 'script='.
As I say I have on occasion wanted to edit these to work around bugs
or do strange things. I don't think taking a copy of the script and
editing that is a better idea than treating the script as a
configuration file.
> I'm sure they are in /etc because in the early days of Xen there was a hope the local admin would do all the work to connect backends and frontends in a way he likes. I think this is not true since more than a decade, the scripts are always tied to the tools version. The API is now mature since a while, there are very few changes in the past years.
The scripts are not "tied to the tools version". They are shipped
with the tools, sure, but we have maintained the interface. There are
even out-of-tree scripts. (I think iscsi has one, for example.)
They are in /etc for the same reason as boot scripts, dhclient hooks,
and so on, are in /etc.
Ian.
diff --git a/m4/paths.m4 b/m4/paths.m4 index 89d3bb8312..0ccc92d0ff 100644 --- a/m4/paths.m4 +++ b/m4/paths.m4 @@ -137,7 +137,7 @@ AC_SUBST(INITD_DIR) XEN_CONFIG_DIR=$CONFIG_DIR/xen AC_SUBST(XEN_CONFIG_DIR) -XEN_SCRIPT_DIR=$XEN_CONFIG_DIR/scripts +XEN_SCRIPT_DIR=${LIBEXEC}/scripts AC_SUBST(XEN_SCRIPT_DIR) case "$host_os" in
In the near future all fresh installations will have an empty /etc. The content of this directory will not be controlled by the package manager anymore. One of the reasons for this move is to make snapshots more robust. As a first step into this direction, move the hotplug scripts to libexec because they are not exactly configuration. Signed-off-by: Olaf Hering <olaf@aepfle.de> --- m4/paths.m4 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)