.TH "doc_decisions_vendor_spec_md" 3elektra "Sun May 29 2016" "Version 0.8.14" "Elektra" \" -*- nroff -*-
.ad l
.nh
.SH NAME
doc_decisions_vendor_spec_md \- Vendor Spec 

.SS "Issue"
.PP
Vendors (distributors, administrators) might want to modify the specification\&. gsettings has a similar feature\&.
.PP
.SS "Constraints"
.PP
There are many constraints in providing such a feature because it is possible to get a inconsistent or unusable specification\&.
.PP
.SS "Assumptions"
.PP
Developers who elektrify their applications do care about good integration and being administer friendly\&.
.PP
.SS "Considered Alternatives"
.PP
.IP "\(bu" 2
implementing a new namespace that gets merged
.IP "\(bu" 2
merge specification files during installation
.PP
.PP
.SS "Decision"
.PP
Provide means that a single specification can satisfy every distribution and administrator\&.
.PP
.SS "Argument"
.PP
.IP "\(bu" 2
Elektra wants to reduce fragmentation, and vendor specific changes obviously is a severe kind of fragmentation
.IP "\(bu" 2
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
.PP
.PP
.SS "Implications"
.PP
Provide means for a single specification to be very good integrated in every system\&.
.PP
.SS "Related decisions"
.PP
.SS "Notes"