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

[bugzilla at redhat.com]

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 #30 from Mario Sanchez Prada <msanchez at igalia.com> 2011-06-02 11:17:19 EDT ---
(In reply to comment #29)
> [...]
> I think you could also package a Git snapshot of flicksoup and use it instead
> of the bundled library. In this case, all changes to the bundled library
> should of course be pushed to the flicksoup repo so that both source pools 
> are in sync and future updates work smoothly. 

Hmmm... the more I think about it the more I regret having started with
flicksoup as a separate thing in the first place. I should have started
everything together and split it later on, then we wouldn't have this problem
now... :/

Currently flicksoup files inside of frogr are not on sync with those in
gitorious (frogr's files are more recent) and they probably will change a
little bit more during the development of frogr 0.6, specially in those
functions related to proxy support.

> If the FPC doesn't grant an exception, this is probably the only alternative. 

If the Fedora Packaging Comitee granted that exception that would be awesome.
As I said, I'm open to (temporarily at least) removing the git repository of
flicksoup in gitorious, and I'm also open, if bundling a static library in
frogr is a problem (as I understand from your words), to merge even more those
files in src/fliksoup with frogr, so they would be compiled just through the
same set of files in the SOURCES variable, in src/Makefile.am.

That way, there wouldn't be anymore a libflicksoup.a frogr would link against,
just the source files as they are, avoiding the problems with Fedora packaging,
if I got it right.

In the future, if I (or anyone else) manage to get the right timespan to make
flicksoup an independent package out of frogr, we would just remove those files
and set the dependency.

But all this, when it comes to releasing frogr 0.5 in fedora, would mean that
such an exception should be granted. Or well... if such an exception was not
granted we could also release frogr 0.5.1 with those modifications in place, in
case you agree is a good idea

If this idea (remove the libflicksoup.a from frogr) was feasible, I'd say is
the best way to go. And if keeping the flicksoup files inside of frogr with the
LGPLv3 license was not a problem for Fedora, then it would be perfect.

> (In reply to comment #26)
> > if I released it
> > now, I couldn't promise I wouldn't break API/ABI in the next releases
> 
> That shouldn't be too much of a problem as long as you bump the soname and
> soversion accordingly.

Yeah, I know, but the problem is other... more related with me feeling
confident and comfortable enough to releasing  the library separately. And
because one reason of another the truth is that I still do not feel like it...

Btw, just in case you wonder, do not worry about me perhaps disliking the idea
of dropping the flicksoup repo from gitorious... actually that wouldn't be that
bad for me, since it would free me from the burden of having to keep two copies
of the same file set on sync, and I could always re-open it in the future when
I feel confident enough to propose flicksoup as an independent package :-).

-- 
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.