Bug 209906 - Review Request: elektra - A key/value pair database to store software configurations
Review Request: elektra - A key/value pair database to store software config...
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ralf Corsepius
Fedora Package Reviews List
: Reopened
: 187430 (view as bug list)
Depends On:
Blocks: FE-ACCEPT
  Show dependency treegraph
 
Reported: 2006-10-07 18:02 EDT by Patrice Dumas
Modified: 2014-02-15 13:33 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-03-26 04:31:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rc040203: fedora‑review+
limburgher: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Patrice Dumas 2006-10-07 18:02:55 EDT
Spec URL: http://www.lmd.jussieu.fr/~pdlmd/elektra.spec
SRPM URL: http://www.lmd.jussieu.fr/~pdlmd/elektra-0.6.4-1.src.rpm
Description: 


Elektra provides a universal and secure framework to store configuration
parameters in a hierarchical key-value pair mechanism, instead of each
program using its own text configuration files. This allows any program
to read and save its configuration with a consistent API, and allows
them to be aware of other applications' configurations, permitting
easy application integration. While architecturally similar to other OS
registries, Elektra does not have most of the problems found in those
implementations.

This package also contains a Berkeley DB backend for Elektra, to let 
Elektra use Berkeley DB databases to store its keys and daemon which can
be used as a proxy for access to the keys.
Comment 1 Patrice Dumas 2006-10-07 18:13:51 EDT
All issues in #187430 have been fixed, except for some names being
too generic. I follow upstream and asked for a change in the name, 
I don't know what will be the outcome, but I think it is acceptable 
as is.
Comment 2 Jason Tibbitts 2006-10-07 21:14:55 EDT
*** Bug 187430 has been marked as a duplicate of this bug. ***
Comment 3 Ralf Corsepius 2006-10-09 10:29:59 EDT
(In reply to comment #1)
> All issues in #187430 have been fixed, except for some names being
> too generic.

I can avoid re-emphasizing my comments from:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187430#c15

In particular:
- header name are too general to all allow them to installed into $(includedir)

-  Still many warnings, which justify doubts on the package  to be installed
into /lib rsp. /bin , /sbin

In addition to that:
- kbd is too general as a program name, c.f.
http://docs.sun.com/app/docs/doc/816-0210/6m6nb7mcf?a=view

- Please explain in detail why you want to ship static libs. As you probably are
aware about, there is a strong tendency to eliminate them.


In addition to that
Comment 4 Patrice Dumas 2006-10-09 11:11:41 EDT
(In reply to comment #3)

> I can avoid re-emphasizing my comments from:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187430#c15
> 
> In particular:
> - header name are too general to all allow them to installed into $(includedir)

I agree, but I'd prefer to follow upstream, and only if they don't 
cooperate start changing things.

> -  Still many warnings, which justify doubts on the package  to be installed
> into /lib rsp. /bin , /sbin

There are less warnings, most of them now corresponds with
error codes not checked, I hope that they are harmless, an audit
of the code is required to know for sure.

But elektra is a bit experimental, and in my opinion apps using it 
are being adventurous, so I am not too worried by those warnings.
If elektra is in /lib, /bin and so on it is because some apps
may use it during boot without /usr mounted, but this won't 
happen magically, apps have to explicitely use elektra, and 
at that point developper know what they are doing.

> In addition to that:
> - kbd is too general as a program name, c.f.
> http://docs.sun.com/app/docs/doc/816-0210/6m6nb7mcf?a=view

It is kdb, not kbd. But I agree that it is too generic anyway, 
but here too, I'd prefer following upstream.

> - Please explain in detail why you want to ship static libs. As you probably are
> aware about, there is a strong tendency to eliminate them.

I think static libs could be usefull, in case one want to be sure
that elektra may still be used within an app even if dynamical 
linking fails. Remember that today most of the apps reimplement
what elektra provides, so the situation today is similar with 
static linking with elektra. It doesn't meeans that I think it is 
wise to link statically against elektra in the general case, and 
the default would be dynamic linking anyway.
Comment 5 Ralf Corsepius 2006-10-09 11:55:38 EDT
(In reply to comment #4)
> (In reply to comment #3)
> 
> > I can avoid re-emphasizing my comments from:
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187430#c15
> > 
> > In particular:
> > - header name are too general to all allow them to installed into $(includedir)
> 
> I agree, but I'd prefer to follow upstream, and only if they don't 
> cooperate start changing things.
It's you who is proposing this package, it's you whose task it is to provide
proper integration => It's your job, not upstream.

> > -  Still many warnings, which justify doubts on the package  to be installed
> > into /lib rsp. /bin , /sbin
> 
> There are less warnings, most of them now corresponds with
> error codes not checked, I hope that they are harmless, an audit
> of the code is required to know for sure.
Then please do it - This package wants to be used at boot up, therefore I am
imposing tighter constraints on it than on ordinary applications.

> > In addition to that:
> > - kbd is too general as a program name, c.f.
> > http://docs.sun.com/app/docs/doc/816-0210/6m6nb7mcf?a=view
> 
> It is kdb, not kbd. But I agree that it is too generic anyway, 
> but here too, I'd prefer following upstream.
kdb isn't much better either.

google for kdb.h ...

> > - Please explain in detail why you want to ship static libs. As you probably are
> > aware about, there is a strong tendency to eliminate them.
> 
> I think static libs could be usefull,
I don't.

> in case one want to be sure
> that elektra may still be used within an app even if dynamical 
> linking fails.
If dynamical linking fails almost nothing works on Fedora.
Comment 6 Patrice Dumas 2006-10-15 06:41:18 EDT
I don't think the potential conflicts are a sufficient reason
to do things differently than upstream, reporting is enough
in my opinion. I don't think that it is up to the packager to 
check the warnings, reporting is enough, especially when the 
warnings may be innocuous.

I have split out the static libraries in another sub-package in the
new version:
http://www.environnement.ens.fr/perso/dumas/fc-srpms/elektra.spec
http://www.environnement.ens.fr/perso/dumas/fc-srpms/elektra-0.6.4-2.src.rpm

The rpmlint warning and errors seems acceptable to me, the last 3
are linked with -static not being recognized by rpmlint:

W: elektra conffile-without-noreplace-flag /etc/profile.d/elektraenv.sh
W: elektra symlink-should-be-relative /usr/lib/elektra/libelektratools.so
/usr/lib/libelektratools.so.1
E: elektra-static devel-dependency elektra-devel
W: elektra-static no-documentation
W: elektra-static devel-file-in-non-devel-package /usr/lib/libelektra.a
Comment 7 Ralf Corsepius 2006-10-16 03:10:35 EDT
(In reply to comment #6)
> I don't think the potential conflicts are a sufficient reason
> to do things differently than upstream, reporting is enough
> in my opinion.

As a reviewer I consider it my duty not only to run "rpmlint", but to check for
a package's qualtity. 

In this particular case, upstream apparently is committing almost all newbie's
faults newbie's can trip over.

> I don't think that it is up to the packager to 
> check the warnings, reporting is enough, especially when the 
> warnings may be innocuous.
Well, I consider it a packager's responsibility to provide safe integration of a
package into the distro and to apply whatever measures are needed.

IMNSHO, this package has not reached a shape to justify inclusion into Fedora. I
definitely will NOT formally review nor approve it.
Comment 8 Nicolas Chauvet (kwizart) 2007-02-20 17:22:53 EST
SRPMS:
http://kwizart.free.fr/fedora/6/testing/elektra/elektra-0.6.4-3.kwizart.fc6.src.rpm
SPECS:
http://kwizart.free.fr/fedora/6/testing/elektra/elektra.spec
Summary:
A key/value pair database to store software configurations

rpmlint errors on source and binaries
E: elektra sourced-script-with-shebang /etc/profile.d/elektra-elektraenv.sh
E: elektra executable-sourced-script /etc/profile.d/elektra-elektraenv.sh 0755
W: elektra-static no-documentation
W: elektra-static-devel no-documentation

About the source script error: the /etc/profiles.d/ directory i have do not
contain any file (which are sh or csh - so executable by definition) which do
not have executable bit set... (if you have some example i will check)
I've checked for examples in glib2 or krb5 but non of theses file remove it...
they do not use %config for one or %config(noreplace) for the other.
I think this file isn't aimed to be checked by used to define their
environnement but use the environnement that conform to the package version...
(i will check by use)
Anyway The packaging guideline should state about this question...

I plan to release cinepaint which requires oyranos which requires elektra (do
you know kafka?!) So hope it will help to do so. I will use it as a base for
oyranos packaging i also hope it will help to solve differents question open
here and to know how to fix them by the examples...

Comment 9 Patrice Dumas 2007-02-21 03:57:56 EST
(In reply to comment #8)

> About the source script error: the /etc/profiles.d/ directory i have do not
> contain any file (which are sh or csh - so executable by definition) which do
> not have executable bit set... (if you have some example i will check)

They are wrong. These are core packages that were not reviewed until 
recently  and many had packaging issues, this will hopefully be solved soon.
(you could even report those issues on the merge review tickets, though
somebody already did it unless I'm wrong).

> I've checked for examples in glib2 or krb5 but non of theses file remove it...
> they do not use %config for one or %config(noreplace) for the other.
> I think this file isn't aimed to be checked by used to define their
> environnement but use the environnement that conform to the package version...
> (i will check by use)
> Anyway The packaging guideline should state about this question...

It is a question that isn't completely agreed. My personal opinion 
is that scripts in /etc/init.d and /etc/profile.d shouldn't be %config
at all. If I recall well, previously I did differently - and I accept
other contributors view.

> I plan to release cinepaint which requires oyranos which requires elektra (do
> you know kafka?!) So hope it will help to do so. I will use it as a base for

I think that you could submit them right now, and have oyranos 
depend on that ticket

> oyranos packaging i also hope it will help to solve differents question open
> here and to know how to fix them by the examples...

Requires(postun): /sbin/ldconfig
isn't needed, with %postun -p the dependency is added automatically.

Otherwise
- I'd like to keep the statically compiled executable, but it could
  be done later when elektra is used in such a way that it needs 
  to be there for recovery. What I'd like is to have the library 
  static package be called static-devel (or devel-static) such that
  the static name is kept for later use for executables.
- your way to package doc is certainly better than mine because
  it will certainly work better with --short-circuit
- about putting things not in /bin and /sbin, it's fine for me, also
  could be reverted if elektra is needed for recovery
- Putting the include file in elektra/ subdirectory implies a change
  in the .pc file(s)

I still haven't ssen the resulting names, to see if it isn't too much
transformation and if it works.
Comment 10 Ralf Corsepius 2007-02-21 04:11:57 EST
I sense some progress ;)

Some remarks at random items:

* Append --includedir=%{_includedir}/elektra to %configure, and all the include
file handling magic in your current spec is superfluous.

* remove --libdir=%{_libdir} from %configure.
It's redundant

* *-devel must own
%{_includedir}/elektra
Comment 11 Nicolas Chauvet (kwizart) 2007-02-21 12:39:27 EST
SRPMS:
http://kwizart.free.fr/fedora/6/testing/elektra/elektra-0.6.4-4.kwizart.fc6.src.rpm
SPECS:
http://kwizart.free.fr/fedora/6/testing/elektra/elektra.spec
Summary:
A key/value pair database to store software configurations

I've added %config(noreplace) as rpmlint remain silent this way.
I asked confirmation on the extras ml for this...
Also used static-devel so rpmlint consider it as a devel package.

I will check how it works with mock fc7 and also start a sight on oyranos...
Comment 12 Patrice Dumas 2007-02-21 17:49:59 EST
(In reply to comment #11)

> I've added %config(noreplace) as rpmlint remain silent this way.

It is better to be correct than shut rpmlint. %config(noreplace) 
seems clearly wrong to me. %config could be acceptable, however.

* the following is unusefull:
Requires(postun): /sbin/ldconfig

* /usr/bin/elektra-kdb_static
should be removed from the main package

* /usr/lib/elektra/*.la shouldn't be shipped

* the scripts would better be in %doc than in /usr/share/elektra/scripts
in my opinion. Or some could be in %doc and others in 
/usr/share/elektra/scripts

* I won't object the prefixing with elektra although I don't like
it that much. However 2 man pages became wrong:
/usr/share/man/man5/elektra-elektra.5.gz
/usr/share/man/man7/elektra-elektra.7.gz

* The *.la files should not be in elektra-static-devel

* The following is a bad idea (although it is likely that I added it):
Requires:       %{_sysconfdir}/profile.d

* to have rpmbuild -bi --short-circuit working, you should add, before
mkdir __doc and mkdir __doc-devel:

rm -rf __doc __doc-devel

Comment 13 Nicolas Chauvet (kwizart) 2007-02-21 18:16:09 EST
Ok i will fix theses...

It builds fine in mock for fc7...
http://kwizart.free.fr/fedora/6/testing/elektra/build.log

quotes:
checking dynamic linker characteristics... cat: ld.so.conf.d/*.conf: No such
file or directory (several times...)
...
Requires(postun): /sbin/ldconfig /sbin/ldconfig
yes i see, i will fix that.

About scripts, is it fine to ln -s to %{_datadir}/elektra from doc since i'm not
sure they were files in doc will have a executable bit set if needed?



Comment 14 Patrice Dumas 2007-02-21 18:34:58 EST
(In reply to comment #13)

> About scripts, is it fine to ln -s to %{_datadir}/elektra from doc since i'm not
> sure they were files in doc will have a executable bit set if needed?

Not really (%doc must not be runtome), but those files should be shipped 
with executable bit unset if they are documentation. The user should know 
how to set the exec bit or call them with an interpreter.
Comment 15 Nicolas Chauvet (kwizart) 2007-02-23 12:41:09 EST
SRPMS:
http://kwizart.free.fr/fedora/6/testing/elektra/elektra-0.6.8-1.kwizart.fc6.src.rpm
SPECS:
http://kwizart.free.fr/fedora/6/testing/elektra/elektra.spec
Summary:
A key/value pair database to store software configurations

Update to 0.6.8 (not sure if timestamp is good as i've took the src.rpm one the
webserver was a little down)...

- There is some new rpmlint errors from the intégration of the init.script
- I've see that there is a segmentation fault on /usr/sbin/elektra-kdbd
- Maybe there is a need to implement PAM acces.
- Scripts directory discution. As you have stated this before i'm not sure %doc
directory allow executable so I would prefer to have them in
datadir/elektra/scripts. If some are not intented to be run and are only for
sample, i suggest that they could be sorted and to be in %doc directory
I will fix this later and take a quick sight on ldap script as Avi Alkalay
suggested...

Here is the current state of art, i will continue next week...
Comment 16 Patrice Dumas 2007-03-06 17:17:23 EST
The use of --program-prefix leads to ugly sed substitutions. This
is an upstream issue, we should fix it in elektra. I'll send
a mail on the elektra list.
Comment 17 Nicolas Chauvet (kwizart) 2007-03-06 18:06:16 EST
Thx for you help!
If you can check i've also a segmentation issues with the elektra Maybe caused
by this --program-prefix changes - or not using /sbin but /usr/sbin ? I don't
know...

Comment 18 Patrice Dumas 2007-03-06 18:10:15 EST
(In reply to comment #17)
> Thx for you help!
> If you can check i've also a segmentation issues with the elektra Maybe caused
> by this --program-prefix changes - or not using /sbin but /usr/sbin ? I don't
> know...

Could you please give more information on how to reproduce the 
segfault?

I doubt it is related with --program-prefix changes or not using 
/sbin but /usr/sbin.
Comment 19 Patrice Dumas 2007-03-07 19:24:50 EST
(In reply to comment #18)

I found the segfault and committed a fix in svn. I didn't fixed the 
real issue, the spec needs to be updated too, but I have more fixes
for upstream and we will have to use the next release anway.
Comment 20 Patrice Dumas 2007-03-08 06:02:29 EST
Things are fixed upstream. We should wait for the next release
now.
Comment 21 Patrice Dumas 2007-03-10 04:55:11 EST
Ralf, I think that all the issues you raise are fixed, 
could you please review:

http://www.environnement.ens.fr/perso/dumas/fc-srpms/elektra.spec
http://www.environnement.ens.fr/perso/dumas/fc-srpms/elektra-0.6.4-2.src.rpm

- update to 0.6.10
- use canonical scriptlets
- minor cleanups
- fix kdbd initscript

Comment 23 Ralf Corsepius 2007-03-12 09:37:34 EDT
(In reply to comment #21)
> Ralf, I think that all the issues you raise are fixed, 
Yes, my comments from #10 seem to be fixed.

> could you please review
Remove this *-static and the *static-devel package and I might consider formally
reviewing this package, as long as they are present, I will not do so.
Comment 24 Nicolas Chauvet (kwizart) 2007-03-12 10:33:13 EDT
If have a problem with starting to work on oyranos (which requires elektra)
It want's to link to a static lib from elektra and also a "filesys" static lib.
yet oyranos (1.7rc7) bundles it own version of elektra ( 6.4 which is not up to
date - maybe a news on libelektra.org can help adoption of the new version 6.10
- i've mailed oyranos developper about this)
 
I'm working on allowing oyranos to uses the dynamic lib - i may start a review
if i have some work in progress...

The -static package bundles a binary file (with it own static lib) It is here in
case of problems and may not be use normally. I wonder if it shouldn't be kept?

Usually if a package bundles a static lib, i must be approved by FESCo. I expect
it won't be necessary...


Comment 25 Ralf Corsepius 2007-03-12 11:13:55 EDT
(In reply to comment #24)
> If have a problem with starting to work on oyranos (which requires elektra)
> It want's to link to a static lib from elektra and also a "filesys" static
> lib.
You won't like what I am going to say now, but it seems inevitable:

Any package that "must use static libs", in 90% of such cases is "plain broken".
Either these developers have no clue what they are doing, or they are doing
something "obscure" and not unlikely to outsmart themselves.

> The -static package bundles a binary file (with it own static lib) It is here in
> case of problems and may not be use normally. I wonder if it shouldn't
> be kept?
There are only very rare occasions where a statically linked application is
really required. In case of a binary in /usr/bin, it almost never makes any sense.
Comment 26 Patrice Dumas 2007-03-12 11:22:06 EDT
(In reply to comment #24)

> I'm working on allowing oyranos to uses the dynamic lib - i may start a review
> if i have some work in progress...

Indeed not using the internal lib is a must.

> The -static package bundles a binary file (with it own static lib) It is here in
> case of problems and may not be use normally. I wonder if it shouldn't be kept?
I consider that acceptable, especially since upstream supports it. 
I don't insist on having it either, although I think it would certainly
match better the user expectations.

> Usually if a package bundles a static lib, i must be approved by FESCo. I expect
> it won't be necessary...

I personally don't adhere to that guideline, for the reason that I think
that FESCo members are less qualified to judge on that matter than
packagers who know more about the uses of the package, and also because
it seems to me that FESCo should never ever have to look at a class of
package.
Comment 27 Patrice Dumas 2007-03-12 11:25:58 EDT
(In reply to comment #25)

> > The -static package bundles a binary file (with it own static lib) It is here in
> > case of problems and may not be use normally. I wonder if it shouldn't
> > be kept?
> There are only very rare occasions where a statically linked application is
> really required. In case of a binary in /usr/bin, it almost never makes any sense.

Statically compiling increase portability a lot in many cases, elektra
is a case where it should be so.
Having statically linked apps may also help recovery.
Comment 28 Ralf Corsepius 2007-03-12 11:29:05 EDT
Ok, you want it the hard way.

MUSTFIX:
- Don't ship the static libs.
- Don't ship the static binary.
Comment 29 Patrice Dumas 2007-03-12 11:35:21 EDT
Nicolas, now we have 2 possibilities
* remove the static parts and let Ralf accept the package
* keep the static parts and you accept the package

I don't care that much either way. I leave that decision to you.

As a side note would you like to be co-maintainer or primary
maintainer of elektra?
Comment 30 Nicolas Chauvet (kwizart) 2007-03-12 11:44:49 EDT
I was thinking about -static binary file that allow to be used with the rescue cd
(not usually used but in case of broken system for any reason)
Maybe the package should be named -recovery to make this clear?
I think the QA would be this way...

yes i'm interested in co-maintainership as secondary maintainer (as you may be
more involve with upstream) unless it prevent me to import the package if i made
the modifications...
Comment 31 Patrice Dumas 2007-03-12 18:51:50 EDT
Here it is, without static parts 
- remove static subpackages

http://www.environnement.ens.fr/perso/dumas/fc-srpms/elektra-0.6.10-2.src.rpm
Comment 32 Avi Alkalay 2007-03-13 08:34:35 EDT
Oyranos started to use the static libs because Elektra was not available on any
distro repo.

Being available on FE provides Oyranos a chance to use the system's Elektra (the
dynamic version) now.

Yes, a static brick is good for rescue situations. But if Elektra will once
become such an essential piece of software, sysadmins and rescue-CD-makers will
find a way to include a dynamic Elektra on it.

I won't bother about eliminating static build process and packages.
Comment 33 Nicolas Chauvet (kwizart) 2007-03-13 09:01:51 EDT
SRPMS:
http://kwizart.free.fr/fedora/6/testing/elektra/elektra-0.6.10-2.kwizart.fc6.src.rpm
SPECS:
http://kwizart.free.fr/fedora/6/testing/elektra/elektra.spec
Summary:
A key/value pair database to store software configurations

Ok so i've cleaned the spec from static package reference... The only difference
with Patrice version is that i've disabled-static in configure but it may only
affect install strep (i also need to remove static lib and binary manually)..
Unfortunately there is a release collision because i've also used relase 2...


Comment 34 Patrice Dumas 2007-03-13 09:16:06 EDT
Ralf, please review the srpm from Nicolas.

The fact that disable-static don't really work is not 
really surprising since static libraries building is rather
specific in elektra (to include backends otherwise dlopened).
I'll have a look as time permits.
Comment 35 Ralf Corsepius 2007-03-23 01:53:31 EDT
(In reply to comment #34)
> Ralf, please review the srpm from Nicolas.
> 
> The fact that disable-static don't really work is not 
> really surprising since static libraries building is rather
> specific in elektra (to include backends otherwise dlopened).
Well, elektra's configuration is pretty, let me put it this way "interesting".

> I'll have a look as time permits.

Though I am not convinced this package to be useful for Fedora nor to be useful
in general and also see several questionable details inside, I don't see any
reasons to not approve this package.
Comment 36 Patrice Dumas 2007-03-24 20:44:38 EDT
New Package CVS Request
=======================
Package Name: elektra
Short Description: A key/value pair database to store software configurations
Owners: pertusus [AT] free dot fr, kwizart [AT] gmail dot com
Branches: FC-6
InitialCC: avi [AT] unix dot sh
Comment 37 Dennis Gilmore 2007-03-25 13:40:12 EDT
Please in the future put full and correct email addresses so that your request 
does not need modification 
Comment 38 Patrice Dumas 2007-03-25 13:52:31 EDT
The email address are available to the spam bots unless 
obfuscated.
Comment 39 Nicolas Chauvet (kwizart) 2007-03-25 15:07:53 EDT
From Extras commit
+Fedora Extras|elektra|A key/value pair database to store software
configurations|pertusus@free.fr,kwizart@gmai.com|extras-qa@fedoraproject.org|avi@unix.sh

There is an typo with my email address: kwizart@gmail.com
I wonder if we should requires branch for devel also?
Comment 40 Dennis Gilmore 2007-03-25 15:57:59 EDT
devel is created by default.  corrected typo
Comment 41 Christopher Meng 2014-02-12 22:57:27 EST
Package Change Request
======================
Package Name: elektra
New Branches: epel7
Owners: cicku kwizart
Comment 42 Gwyn Ciesla 2014-02-13 07:52:46 EST
Git done (by process-git-requests).
Comment 43 Avi Alkalay 2014-02-15 05:02:44 EST
Folks, elektra is already in Fedora.

'yum install elektra' works and you'll get version 0.7.0.

I was the original developer of this software years ago but now maintenance was taken over by Markus Raab and others.
Comment 44 Ralf Corsepius 2014-02-15 13:33:13 EST
(In reply to Avi Alkalay from comment #43)
> Folks, elektra is already in Fedora.

You are confused (rsp. insufficiently familiar with Fedora):

C.f. https://bugzilla.redhat.com/show_bug.cgi?id=209906#c41

=> This is an epel7 branch request and not a review request.

Note You need to log in before you can comment on or make changes to this bug.