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.
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.
*** Bug 187430 has been marked as a duplicate of this bug. ***
(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
(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.
(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.
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
(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.
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...
(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.
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
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...
(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
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?
(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.
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...
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.
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...
(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.
(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.
Things are fixed upstream. We should wait for the next release now.
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
Sorry, it is http://www.environnement.ens.fr/perso/dumas/fc-srpms/elektra-0.6.10-1.src.rpm
(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.
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...
(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.
(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.
(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.
Ok, you want it the hard way. MUSTFIX: - Don't ship the static libs. - Don't ship the static binary.
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?
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...
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
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.
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...
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.
(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.
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
Please in the future put full and correct email addresses so that your request does not need modification
The email address are available to the spam bots unless obfuscated.
From Extras commit +Fedora Extras|elektra|A key/value pair database to store software configurations|pertusus,kwizart|extras-qa|avi There is an typo with my email address: kwizart I wonder if we should requires branch for devel also?
devel is created by default. corrected typo
Package Change Request ====================== Package Name: elektra New Branches: epel7 Owners: cicku kwizart
Git done (by process-git-requests).
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.
(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.