Alexander Strange <[EMAIL PROTECTED]> writes:

>>> There's another new package for it here:
>>> http://sourceforge.net/tracker/index.php?func=detail&aid=1942780&group_id=17203&atid=414256
>>>
>> 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
> anymore.

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.

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

> So, I guess I'd rather use this one, since we can follow the  
> differences more easily.

It's up to you.

Sébastien

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel

Reply via email to