El Sun, 31 Oct 2010 10:38:38 +0100 Ansgar Burchardt <ansgar@43-1.org> escribió: > Hi, > > Tony Palma <xbytemx@gmail.com> writes: > > Ansgar Burchardt <ansgar@43-1.org> escribió: > >> Tony Palma <xbytemx@gmail.com> writes: > >> > I am looking for a sponsor for the new version 1.2a-8 of my > >> > package "lightspeed". > >> > >> I did take a brief look at your package (not a full review) and > >> here are some comments: > >> > >> · debian/changelog: What change does > >> * Obsolete package removed since 1.2a-6. Closes: #601353 > >> refer to? > >> > > I reassigned to the 'Changed ftgl-dev to libftgl-dev package.'. > > Okay, that is easier to understand. > > >> · You use the new source format 3.0 (quilt), but all changes to > >> the upstream source are stored in a single large diff. They > >> should be split into individual patches. > >> > >> · It would be nice if generated files such as ./configure were not > >> included in the diff, but generated at build-time instead. This > >> makes the diff much shorter and easier to review. > >> > >> · You build depend on autotools-dev, but seem not to replace > >> config.{guess,sub} with more recent versions. > >> > > The large diff is generated by autoconf and automake, since the last > > update of helper files was on 2006-02-23. What is more recommended > > in this case, let it or split it or using dpkg-source > > --extend-diff-ignore to remove some files from the diff? > > One advantage of the new source format is that it encourages > maintainers to separate changes to the upstream source in several > patches providing changes for a specific feature (bug fix). This > makes it easier for upstream developers to review changes and apply > them. For lightspeed, there are quite a lot of changes: i18n support, > porting to Gtk2, use of FTGL for fonts, ... Ideally these would be > applied upstream[1] or split in several patches. > > Without using this feature, there is (IMO) not much advantage over the > old source format.[2] > > [1] But the project of Sourceforge looks not really alive. You > might want to ask the current maintainer to take over the project and > maintain it upstream as well. > > [2] You can also use 3.0 (quilt) similar to the 1.0 format by > including all changes in a single diff, see the > --single-debian-patch option for dpkg-source. > > About the generated files: as I said, I would exclude the changes to > ./configure and friends and instead just run autoconf/automake in > debian/rules to regenerate them (if required). How you exclude them > is left to you: just rm the files in the clean target or add an > option for dpkg-source to debian/source/options. > > In any case, it is recommended to update config.{guess,sub}. I think > you did intend to do this (the package build-depends on > autotools-dev), but you still need to copy the files in debian/rules. > > See also <file:///usr/share/doc/autotools-dev/README.Debian.gz>. > > Regards, > Ansgar > > PS: I think we could continue discussing on the list, no need to > switch to private mail. I notified the author and upload the package to mentors with a very large patch(build-update.diff). Now I'm using dh $@ --with autotools_dev and their respectives overrides, to manage the updates of config.{guess,sub}. Regards, Tony Palma.
Attachment:
signature.asc
Description: PGP signature