Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=708765 --- Comment #26 from Mario Sanchez Prada <msanchez@xxxxxxxxxx> 2011-06-02 05:20:16 EDT --- (In reply to comment #24) > CFLAGS also defines some preprocessor constants (-DG_DISABLE_ASSERT > -DG_DISABLE_CHECKS -DG_DISABLE_CAST_CHECKS) that probably have to be added when > overwriting CFLAGS in the make statement. I'm not sure if they are actually > required, though. > > Mario Sanchez Prada, since it's a bad idea to hard-code -g0 and -O2 in > configure.ac, I suggest to remove them in the next release. I did it because it was handy for me, but in the end what I do need for development are the flags when debug mode is enabled. I actually don't care much about those others in release mode, so I agree and have already removed them for the next release: http://git.gnome.org/browse/frogr/commit/?id=bb99f7443acd6d247e7494f4eced8d3635ec2c30 > Also, the source headers contain a wrong FSF address. It's recommended to use > the wording mentioned in COPYING: > You should have received a copy of the GNU General Public License > along with this program. If not, see <http://www.gnu.org/licenses/>. Fixed in master: http://git.gnome.org/browse/frogr/commit/?id=33573b2f8b9d8b261dbcba688a9d422e5a3f8a1f > frogr seems to use the bundled library flicksoup (src/flicksoup) which is > available at http://gitorious.org/flicksoup. This is not allowed in Fedora. > The library must be packaged separately. > https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries Hmmm... we have an issue here, because that library is not mature yet to be published independently, and without it frogr won't work, so we need to find a solution for it if we want to ship frogr in Fedora. But first, let me tell you why this situation of having frogr bundling a, in theory, separate library: I started developing flicksoup (yes, I also hold the authorship and copyright over it) back in 2009 when frogr was still using flickcurl to communicate with flickr, hoping that at some point I could release flicksoup and then just link frogr against it. However, mainly due to my permanent lack of (contigous) time for these tasks, flicksoup ended up being stuck at some point, as well as frogr, because of a kind of an egg-chicken problem: frogr didn't evolve because flicksoup was not ready yet, and flicksoup didn't evolve because there was no specific application (frogr) using it that drove the development of that library in some way (because, due to my lack of time, building a 100% Flickr API complete library was completely out of scope). So, at late 2010 I decided to just move the sources of the flicksoup library inside frogr so I could actually use it inside of that app to replace flickcurl, via static linking... and that actually worked pretty well, since I was able not only to replace flickcurl in a frogr that only uploaded pictures by then (no sets, no groups, no cancelling operations, no error messages...) in the way I always wanted to: through a GNOME-like library. And so far, the situation was that I haven't had much time to think about releasing flicksoup so I kept on developing changes for it just inside frogr, and dumping every now and then those changes into its gitorious repo, just in case someone wanted to use what I had in there, which is possible to build and install as a shared library. And whenever I thought about that, I always came up to the conclusion that the library was not mature enough (if I released it now, I couldn't promise I wouldn't break API/ABI in the next releases), so I decided to wait and keep using it this way... And now we have a situation because of this so I, as the author and copyright holder of both frogr and flicksoup, propose the following solution, if possible: A. Stop saying all around (frogr web site, package descriptions, internal files in frogr...) that Frogr "uses the flicksoup library... blablabla", and stop treating that as if it were a separate and independently maintained library (which it is not, it's just a dump of what I develop inside frogr). B. Use the same license for files inside src/flicksoup than for the rest of frogr, that is, the GNU GPLv3 license. C. If necessary, I could even temporarily remove the flicksoup repository in gitorious to strenght the idea of flicksoup not being a separately maintained library (yet). When ready, if that ever happens (hope so!), I would do the required changes by then: release flicksoup as a separate library, remove the flicksoup-related files from frogr, and make frogr depend on flicksoup. D. ... anything else? <-- put your additional suggestion here IMHO, this makes sense seems the truth is that, as I said, nos the flicksoup repository is just a dump for the changes I do in those files inside frogr, and it's actually kind of redundant thing, so it would even make sense to drop it even if this issue haven't had arised because of packaging frogr for Fedora. What do you think? -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review