[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: lightspeed (updated package)

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

Regards, Tony Palma.

Attachment: signature.asc
Description: PGP signature

Reply to: