[Bug 708765] Review Request: Frogr - Flickr Remote Organizer for GNOME

bugzilla at redhat.com bugzilla at redhat.com
Thu Jun 2 09:20:18 UTC 2011


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 at igalia.com> 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.



More information about the package-review mailing list