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