Re: Ok to use upstream doumentation as-is (i.e. not regenerate)?
On Sun, 05 Jun 2011, Jonas Smedegaard wrote:
> On 11-06-05 at 09:48am, Henrique de Moraes Holschuh wrote:
> > On Sun, 05 Jun 2011, Jonas Smedegaard wrote:
> > > On 11-06-05 at 05:39am, Vincent Bernat wrote:
> > > > On Sat, 4 Jun 2011 21:54:11 +0200, Jonas Smedegaard wrote:
> > > > >What I do is use upstream provided tarballs, then put aside
> > > > >autotools-generated files, then autogenerate myself, and in the
> > > > >clean rule put back the upstream-provided files (because I want
> > > > >not only minimal required build routines idempotent but also
> > > > >building with git-buildpackage).
> > > >
> > > > In the clean rules, you can just delete those autogenerated files.
> > >
> > > True for a normal build. Not true when building from git.
> > >
> > > Yes, there are other possible approaches than restoring (i.e. adding
> > > them to .gitignore) but simply deleteing is not enough.
> >
> > Well, we've known for more than 10 years that commiting any
> > auto-generated file to the [development] VCS tree is a Bad Idea. It
> > was a lot worse with CVS than it is with git, of course, but it has
> > always been trouble.
>
> Depends on what you want to track in your VCS. I want to track upstream
> released sources and our changes to them.
That would be why I specified the development tree as the one for which
Best Known Practice is to never track auto-generated files.
What you track in downstream trees or release trees depends on what is
auto-generated in that tree, after all.
IME, it is worth keeping in mind that git can be quite UNhelpful if you
decided to not track anymore something you used to in that history branch.
That could be a shortcoming of my git skills, though (in which case I'd
appreciate some hints on how to get git to stop paying attention to a
previously tracked file in another thread or by private email. gitignore
seems not to be enough across merges from a branch that does track that
file).
> Discussion here is the cases when upstream intended some files to be
> treated as static but we want to regenerate anyway - and still preserve
> pristine source.
Best practice in Debian is to rebuild from source everything you can rebuild
from source. This keeps upstream honest, forces you to detect missing
prefered source files, uncovers bit-rot, and improves overall package
quality.
However, it does so at the expense of more work (sometimes a LOT more work)
for the downstream (Debian) maintainer. Sometimes that cost is too high to
tack at once when packaging (or at all), but IME that would be the
exception, and not the rule... and the maintainer *IS* supposed to have a
decent knowledge of the build systems his upstream uses (often, aquiring
that knowledge can be very annoying or frustating) to do his job right. It
can [easily] happen that you will find yourself fixing upstream's build
system and negotiating with upstream for them to incorporate those updates.
I abid to that principle on all packages I maintain, to the point of
regenerating raster images in documentation from their xfig/svg sources, for
example.
> I already wrote that there are multiple approaches. Seems you
> implicitly suggest to let go of preserving pristine source.
I have always advocated that the task of preserving pristine source is
restricted to the pristine tarball. Sometimes we cannot even do that, and
have to remove undistributable files. I advocate that the Debian package
tree, after unpacking, cleaning and patching, is to build the best possible
Debian package: it has no ties to the task of distributing upstream pristine
source, that would be a job for the upstream tarball and upstream
repositories in the first place.
Although it should NOT make it very hard to produce patches that can be sent
upstream. Our new source package formats have mostly solved this problem,
if not always in the best possible way for a given package, it certainly
solves it to an acceptable level.
And if you happen to be both upstream AND downstream, Best Known Practice
has been to separate both tasks (although they *can* live in the same git
repository, etc) for a long time. That helps a lot should you happen to
find yourself with more downstream maintainers (other distros), or even
ports (other kernels).
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: