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 <[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.
Sounds good.
- 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.
Right, I disliked it too - I had it in there because my computer was
just
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
it?
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.
OK.
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? :)
-------------------------------------------------------------------------
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
