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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110605153317.ga25...@khazad-dum.debian.net