Spec URL: http://www.republika.pl/belegdol/rpmstuff/libundo.spec SRPM URL: http://www.republika.pl/belegdol/rpmstuff/libundo-0.8.2-1.src.rpm Description: Libundo is a simple, easy-to-use library which manages recording and playback of undo/redo information for application developers. It is designed to be simple to plug in to existing applications and require only a minimal amount of support code be written to support multi-level undo/redo. Libundo handles all the details of determining what has changed after an undoable action is performed, recording that information and saving it for use when an undo is performed. Libundo makes it easy for application writers to give end users what they want. Package builds fine in mock (fc6/i386) and rpmlint is silent.
Some remarks: This package is causing me some gripes. 1. undo.h is being installed into /usr/include. 2. undo.h isn't C++-safe (it lacks the extern "C" guards 3. IMO, calling a library "undo", letting it contain symbols being prefixed "undo_*" and letting its headers provide defines such as "UNDO" isn't necessarily a clever design. None of these issues are blockers for inclusion into FE, but at least #1 and #2 are sufficient reason for me not to want "to dive into a formal review", sorry.
Well, I could reply with a quote: “we don't create evil, we only package it”. I could add extern C guards if someone could tell me how to do so. As for installation dir, I think that putting a single header into its own subdir is a bit of an overkill.
(In reply to comment #2) > Well, I could reply with a quote: “we don't create evil, we only package it”. ... and it's task of a review not to let pass through all kind of junk ;) > I could add extern C guards if someone could tell me how to do so. You should find this in all C-books having been released since 1989: #ifdef __cplusplus extern "C" { #endif .... #ifdef __cplusplus } #endif > As for > installation dir, I think that putting a single header into its own subdir is a > bit of an overkill. The number of headers doesn't matter. One single header is as evil as is a dozen. /usr/include is in the compiler's default header search path, so any poorly designed package installing a header inside is likely to conflict with other headers.
Well, what is the status of this bug??
Seriously? I am too stupid to fix the issues :( Know nothing about programming...
In order to be a package maintainer, you must have some ability to handle basic programming tasks. Not very much, really, but some. So what should happen to this ticket? If the issues can't be fixed, I suppose it should be closed.
Well, I have some very basic knowledge, which was enough for other packages I do maintain, comment #5 was a bit sarcastic. Anyway, I have no interest anymore in this package - LabPlot made it into Fedora without it.