Now that I'm done with finals, I can reply to all my email.
On Apr 30, 2008, at 6:50 PM, Sebastien Maret wrote:
> Alexander Strange <astrange@...> writes:
>>>> There's another new package for it here:
>>> As noted above, my patch follows your original packaging way.
>>> Another one seems to make some big changes in packaging.
>>> It's difficult for me to say which is better.
>>> Which one do you like?
> Hang on a second here. I posted this package on the trackers *two
> weeks ago*, and I offered to maintain it. I spent a lot of time
> updating and testing this package. What's the point of duplicating the
> efforts? Before starting working on updating a package, it we would
> good if poeple could check on the tracker that nothing has been
> submitted yet. Maintainers time is a scarse ressource that should be
> used more wisely.
>> Well, the differences I see are:
>> - This one is a diff from the package I know works. I like that a
>> lot better, since I haven't tried the rewritten one yet.
>> - The other one patches it to use 'open' for help reading.
>> I'm not sure what it does without that, but it might not work without
>> a 'firefox' command.
> Without the patch, Gimp tries to open the help file with firefox, and
> complains if you don't have it installed. The open command will browse
> the documentation with whatever default browser you're using in OS X.
>> - The other one gets rid of the variants. I'd like to keep -svg, but
>> - noprint can go. It's already broken and apparently not necessary
> In my experience, packages with two many variants confuse new users,
> because they all have the same short description. So if you have no
> clue about what -svg of -print is, you're stuck. I know that there is
> usually more information in the DescDetails, but beginners don't
> always read this. From the maintainer point of view, you need to
> compile every variants to make sure that they all build and runs fine,
> and this takes some extra time. This is why I was suggesting to get
> rid of these variants.
Right, I disliked it too - I had it in there because my computer was
too slow to keep up to date with -svg enabled; it practically doubles
the dependencies. These days it's not as bad, but I wonder if anyone
else using the package doesn't want all of GNOME installed just to use
If we had a binary distro, then it could just be a splitoff and that
would be fine.
For now, I guess it's not really important.
>> - I'd prefer gimp-help in the same package since it's only useful
>> for this version.
> Upstream version of the Gimp and the gimp documentation aren't updated
> at the same pace. Having both in the same package forces you to rev-up
> the Gimp and rebuild it everytime you update the documentation.
>> And this one strips debug symbols on everything (since it's large),
>> while the rewritten package gets rid of that. I don't think we have
>> a policy about this, but since the package is pretty big I don't see
>> any harm in it.
> I don't see any harm either, except maybe if poeple find an (upstream)
> bug and want to submit a backtrace.
> The other difference is that my package have Python enabled.
Don't Python bindings need -py24/25 variants?
>> So, I guess I'd rather use this one, since we can follow the
>> differences more easily.
> It's up to you.
Can you make it diffable? :)