Re: RFS: tupi -- 2D Animation design and authoring tool
Hi,
Including debian-mentors@ so other people can chime in -- I thought
that I already did in my initial reply, sorry.
2011/12/29 Dmitry Smirnov <onlyjob@member.fsf.org>:
>> 1) README.source in debian/ is unnecessary, I think
>
> Sorry, I'm not sure what do you mean - where did you find README.source ???
> In tupi package I don't have it...
Actually, I unpacked orig.tar.gz and then yours on top, without
realising that upstream already has a debian/ dir. So, forget about
this one.
>> 2) If you want hardening flags, you can depend on debhelper >= 8.9.0~
>> and use compat=9. debian/make.mk is unnecessary, IMO
>
> You're right, but I'm not too confident using compat=9 until it will be
> stabilized.
> I like include for the explicit reference to variables initialization.
> I think such things are better left visible.
About hardening flags it's OK, it was just a suggestion.
But I don't understand how debian/make.mk is used if it's not included.
>> 3) In control file, the long description should be much longer and
>> explain what actually does
>
> Yes, true.
> The problem is that I'm not familiar enough with tupi to write long
> description.
> I can't borrow description from ktoon package because I'm not sure how well
> its description applies to tupi.
> In regards to long description I found nothing useful neither on tupi web site
> nor in embedded help... :(
>
> Any ideas?
Well, you can tell upstream that their provided information is not
very clear. But I found this, which contains a bit more information:
http://www.maefloresta.com/portal/about
A mix of some of the points in "Tupi is" plus the "features" section
below would be fine, I think.
In any case, I advise you to communicate with upstream when you
encounter problems like these and you have to make some decisions. In
my experience they're usually happy to help to get their packages in
Debian (and... beyond -- all the derivatives), and will help you to
avoid ugly things like the chmods in rules in future releases.
>> 4) You can use Breaks/Replaces on ktoon if you really want to show
>> that it provides a replacement for ktoon
>
> Thanks for advice, I'll do that.
[ left this bit so debian-mentors@ folk can correct me if appropriate ]
>> 5) I think that debian/postinst, just calling ldconfig, is also unnecessary
>
> No, it's calling 'update-menus' only. I avoid ldconfig by
>
> override_dh_makeshlibs:
> dh_makeshlibs --noscripts
Again, this is something from upstream's debian/. You don't have the
"debian/postinst" file, so my comment is irrelevant.
>> 6) Not completely sure, but I think that you can get rid of this
>> conversion and use the .png in the menu/.desktop files
>>
>> convert launcher/icons/tupi_32x32.png
>> $(PDIR)/usr/share/pixmaps/tupi_32x32.xpm
>
> I already tried it but lintian didn't like that - see "menu-icon-not-in-xpm-
> format" http://lintian.debian.org/tags/menu-icon-not-in-xpm-format.html
Ahm, I am not sure if this bit (or the Debian menu thing altogether)
is a bit obsoleted with Freedesktop XDG guidelines? Otherwise you're
correct.
Btw, the debian/desktop linking to a .desktop file contains this path,
which if unmodified it's incorrect:
/usr/local/tupi/bin/tupi
>> 7) I am not sure that the magic things that you do with shlibs are the
>> best way to do it -- just a hint for other reviewers more
>> knowledgeable than me :)
>
> I'm not sure how to do it better. CMAKE is not very nice and alternative way
> could be patching upstream CMAKE files to build libraries in intended
> directories, in which case implications will be the difficulties with future
> maintenance.
> So I'm merely moving libraries where they belong after build phase - it
> appears to be easy enough.
Does the project use CMake at all?
I think that you can for example use "--libdir=/usr/lib/" in
debian/rules (I think that there's no need for this PDIR), removing
the /tupi/ end from there would allow you to not have to move things
later.
Anyway, *again* I was refering to debian/shlibs file in upstream's
debian/, not yours :o)
>> Other than that, it looks like an interesting piece of software, I
>> hope that it gets into Debian. Thanks for your effort!
>
>
> Thank you so much for your review.
> I hope you found tupi useful.
>
> I hope it'll find its way to Debian eventually, but sponsors are so hard to
> find...
>
> I wish you all the best for the new year.
BTW, I think that I already told you that I'm not a Developer, just a
poor Maintainer, so I cannot sponsor packages. But hopefully this
review will help you to get closer to uploading the package to Debian.
Thanks for your efforts and happy celebrations for you too!
Reply to: