Vendors (distributors, administrators) might want to modify the specification. gsettings has a similar feature.

There are many constraints in providing such a feature because it is possible to get an inconsistent or unusable specification.

Developers who elektrify their applications do care about good integration and being administer friendly.


\begin{DoxyItemize}
\item implementing a new namespace that gets merged
\item merge specification files during installation
\end{DoxyItemize}

As found out during implementation of \hyperlink{autotoc_md618_src_plugins_specload_README_md}{specload}, only a very limited subset can be modified safely, e.\+g.\+:


\begin{DoxyItemize}
\item add/edit/remove {\ttfamily description}, {\ttfamily opt/help} and {\ttfamily comment}
\end{DoxyItemize}


\begin{DoxyItemize}
\item Elektra wants to reduce fragmentation, and vendor specific changes obviously is a severe kind of fragmentation
\item providing vendor overrides/fallbacks might be an excuse to not provide better typing or general overrides/fallbacks features which would avoid the need for a vendor overrides/fallbacks at all
\end{DoxyItemize}

Provide means for a single specification to be very good integrated in every system.