Bug 221184

Summary: Review Request: libundo - Undo/redo information managing library
Product: [Fedora] Fedora Reporter: Julian Sikorski <belegdol>
Component: Package ReviewAssignee: Nobody's working on this, feel free to take it <nobody>
Status: CLOSED WONTFIX QA Contact: Fedora Package Reviews List <fedora-package-review>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhide   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-07-06 16:59:01 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 201449    

Description Julian Sikorski 2007-01-02 15:02:25 EST
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.
Comment 1 Ralf Corsepius 2007-01-03 03:59:44 EST
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.
Comment 2 Julian Sikorski 2007-01-09 10:15:12 EST
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.
Comment 3 Ralf Corsepius 2007-01-09 11:54:27 EST
(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.
Comment 4 Mamoru TASAKA 2007-06-05 13:12:47 EDT
Well, what is the status of this bug??
Comment 5 Julian Sikorski 2007-06-05 15:42:58 EDT
Seriously? I am too stupid to fix the issues :( Know nothing about programming...
Comment 6 Jason Tibbitts 2007-07-06 14:11:30 EDT
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.
Comment 7 Julian Sikorski 2007-07-06 16:59:01 EDT
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.