Re: Dealing with autotools
On Mon, May 11, 2009 at 10:04:13AM +0200, martin f krafft wrote:
also sprach Stefano Zacchiroli z...@debian.org [2009.05.10.1616 +0200]:
I _think_ that Manoj's point was more about the fact that
re-creating the auto* files are not (necessarily) part of the
trust relationship that users put into the pristine-ness of
upstream tarball.
I am not sure I parse you correctly. Are you saying distro packagers
should or should not recreate auto* files?
Sorry for the unclear wording. I'm saying that the trust our users
have in the pristine-ity of upstream sources should not rely on the
fact that we do not change auto* files.
Hence if, for any reason, we find appropriate to recreate auto* files,
we should do that. In particular, if it helps in syncing with upstream
VCSs and get rid of tarballs, let's recreate auto* more often!
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: Dealing with autotools
also sprach Toshio Kuratomi a.bad...@gmail.com [2009.05.09.2122 +0200]: 3) sha1sum tarball just downloaded matches with sha1sum tarball used to build package. (If you're the maintainer, you don't have to do step 3) you *should* though, and insist on a trust path to the author, or else all I ever have to do to harm all Fedora people is DNS-poison a Fedora maintainer's connection. Well -- the reason that the Fedora maintainer doesn't have to do #3 is that there isn't a package until the fedora maintainer puts it together. Ah, I meant: In response to DNS poisoning, the only ways I know of to get around that are: 1) Check against the tarballs in other distros packages. 2) Upstream provides gpg signatures of either the tarball or a checksum file. The maintainer should ensure that the tarball used to create a package is pristine, just like s/he should ensure that building from a VCS tag has the desired effect. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems (a)bort, (r)etry, (p)retend this never happened digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: Dealing with autotools
also sprach Manoj Srivastava sriva...@acm.org [2009.05.10.0030 +0200]: If I may sum it up in my own words and mix it with my own opinion, then distributions like Debian aren't really necessarily the target audience of the autotools output and it might make a lot more sense for us to build from VCS. This means that autotools would become part of the build process *and* that we rid ourselves of the dogma of distributing pristine tar sources. Huh? These do not logically follow. I always autoreconf during the build process for my Debian packages, and yet, I also ship pristine sources. I see no contradiction. The files generated by autotools are not in VCS, so when you build from VCS, they don't exist and need to be created as part of the build process. No tarball involved anymore. With hibernate, I have an interesting problem: upstream provides tarballs, and the VCS source is properly tagged, but SVN:keywords are in use. So if I build against VCS and create the Debian diff against the pristine tarball, the Debian diff will /revert/ $Id:$ expansions, e.g. - $Id: author date snapshot whatever$ + $Id:$ which isn't ideal either. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems infinite loop: see 'loop, infinite'. loop, infinite: see 'infinite loop'. digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: Dealing with autotools
On Sun, 2009-05-10 at 09:05 +0200, martin f krafft wrote: also sprach Manoj Srivastava sriva...@acm.org [2009.05.10.0030 +0200]: If I may sum it up in my own words and mix it with my own opinion, then distributions like Debian aren't really necessarily the target audience of the autotools output and it might make a lot more sense for us to build from VCS. This means that autotools would become part of the build process *and* that we rid ourselves of the dogma of distributing pristine tar sources. Huh? These do not logically follow. I always autoreconf during the build process for my Debian packages, and yet, I also ship pristine sources. I see no contradiction. The files generated by autotools are not in VCS, so when you build from VCS, they don't exist and need to be created as part of the build process. No tarball involved anymore. They aren't exclusive though. With current practices there is effectively a Debian upstream branch from the VCS, which contains thes history of the tarballs that made up the source packages. Even when building from a VCS it is possible, and I would say encouraged, to maintain this branch. That branch can contain the autotools files. The process of packaging a new upstream snapshot is then to export a tarball from the desired revision, add autotools files to that tarball, and then import that back to the Debian upstream branch, add pristine-tar information, and then merge to the packaging branch (or do whatever machinations are required to get the final tree to build the source package from). (I actually think autotools at build time isn't a bad thing, so you could just import a plain export tarball instead and do that, it obviously depends on your rules file though) The above ensures that you get repeatability with the pristine-tar information in case you need a -2 upload, and correctly represents what happened in the case where there was some transformation done to the VCS tree to get the tarball, as this transformation will be in the diff between the imported tarball revision and the revision that it was taken from. I am aiming to make this process very easy in bzr-builddeb, as I feel it should be *the* way to pull in new upstream changes. (Upstream has released a tarball from a tag? Use that tarball rather than a generated one. Upstream has no public VCS? Just import the tarball without the extra parent.) The above, with the exception of a transformation of the tarball, is all a single command in the latest versions. I'm interested in adding the transformation step, but I haven't decided what the best way is yet, suggestions welcome. Some ideas: 1. Have an option to the command (and possibly a config option) that specifies the transformation (and allow $SHELL for those that don't value repeatability). The difficulty with this is that sometimes I want the command to actually produce a tarball (setup.py sdist is crucial for one project that I package), so there has to be some way to pick up the resulting tarball. 2. Do something similar to get-orig-source (though I would like that to be replaced with something a little more useful anyway). This is basically the same as above, but encodes the process in to the source package, so doesn't require the use of the particular tool to get a good result. It's possible that an improved get-orig-source would allow this to easily work. As I said, suggestions welcome, I think this could be one useful thing for the project to come up with without having to come up with a complete solution for packaging in a VCS. Thanks, James ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: Dealing with autotools
On Sun, May 10, 2009 at 09:05:25AM +0200, martin f krafft wrote:
also sprach Manoj Srivastava sriva...@acm.org [2009.05.10.0030 +0200]:
Huh? These do not logically follow. I always autoreconf during
the build process for my Debian packages, and yet, I also ship pristine
sources. I see no contradiction.
The files generated by autotools are not in VCS, so when you build
from VCS, they don't exist and need to be created as part of the
build process. No tarball involved anymore.
I _think_ that Manoj's point was more about the fact that re-creating
the auto* files are not (necessarily) part of the trust relationship
that users put into the pristine-ness of upstream tarball.
I personally agree with that. As such, in a near future I would have
no problem in letting user putting their trust in the checksum of our
upstream branch being in sync with the checksum of upstream tag. The
main drawback of that is requiring homogeneity of VCS technology
between packagers and upstream.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: Dealing with autotools
also sprach Manoj Srivastava sriva...@acm.org [2009.04.15.1702 +0200]: In my experience, while that used to be true, it has not been the case for some time now. This topic came up on debian-devel: http://lists.debian.org/debian-devel/2009/05/msg00021.html If I may sum it up in my own words and mix it with my own opinion, then distributions like Debian aren't really necessarily the target audience of the autotools output and it might make a lot more sense for us to build from VCS. This means that autotools would become part of the build process *and* that we rid ourselves of the dogma of distributing pristine tar sources. Even though those are nice in theory, I've always wondered who actually checks them for authenticity, and if so, then *why*. Do they check /every/ source package? Do they check that the binary packages actually stem from those sources? Why are they using Debian? Building directly from VCS seems a lot saner to me. There is no reason why autotools couldn't also be used to create tarballs by upstream for all the other consumers, but in the distro context, pristine tarballs seem a bit limiting and possibly a step backwards. Anyway, this is my summary and mixed with my opinion. Feel free to disagree and voice your counter-arguments! -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems if one cannot enjoy reading a book over and over again, there is no use in reading it at all. -- oscar wilde digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: Dealing with autotools
martin f krafft wrote: also sprach Toshio Kuratomi a.bad...@gmail.com [2009.05.09.1842 +0200]: There are advantages to using tarballs. Whether they outweigh the convenience of building directly from VCS is certainly up for debate (and has been debated many times on Fedora devel list, among other places ;-) Pointers always welcome. ;) heh. My lack of enthusiasm for trawling through the old threads is precisely why I try to remember the reasons that made sense and never go back there :-) One of the reasons I remember as actually having validity was that tarballs have a large test base vs an SCM snapshot. (Even if you build from a tag, you have to depend on upstream having tagged the correct version that actually got into the tarball). Isn't this something the maintainer could quickly check? Not nearly as quickly or as easily as verifying that the tarball is pristine. The process for verifying the tarball is: 1) Is source url canonical? 2) Download tarball from source url. 3) sha1sum tarball just downloaded matches with sha1sum tarball used to build package. (If you're the maintainer, you don't have to do step 3) If you're verifying that a SCM tag matches the rleased tarball, you start at step #3 and add the following steps: 4) Pull the latest source from the repo 5) untar the tarball 6) Diff between the source repo and the tarball 7) For the differences between the source repo and tarball check that: * the differences are due to a file generated in the creation of the tarball (like configure or Makefile.in) * files that won't matter to the build (upstream has a HOW_TO_RELEASE file in the repo that isn't in the tarball) * other things that are more subtle :-( (permissions on files, versions substituted into files at tarball creation time, etc) Also, are you sure of the large test base? The most important package I maintain is mdadm, and I don't know a single person who uses it directly, other than through Doug's or my packages. I admit I don't know any !(Fedora||Debian*) users though, except for upstream himself, who uses OpenSuse. mdadm ist Linux-only, the whole picture changes when you think about something like postfix. However, do you think that those folks who rebuild their software for every upstream release are really going to be a better test base than a new postfix package with 10 days to survive in Debian unstable (or the same concept for other distros)? Yes. One of your assumptions is wrong. You limit the other people to those folks who rebuild their software for every upstream release. In fact, distributions are not going to all switch to a snapshot model immediately (some may not do so until upstreams stop releasing tarballs.) So you could have the set of Debian and Ubuntu users using a snapshot while Fedora, Red Hat, Gentoo, NetBSD, Freebsd, MacOS-fink, Solaris, OpenSuSE, (et al) using the tarball. Even if we get a significant portion of distros basing off of snapshots instead of release tarballs, we still have the problem of which snapshot is being used. It's nice to assume that people will only use a tag representing a release but I doubt that that's what will happen in practice. Working with upstream's repository directly makes it easy to base your package against something slightly newer than the release that just picks up this one tiny bugfix and oh, this other small feature, and... So yes, I think the base of testing of a single tarball now is much higher than what we'll see collectively even if we all go to snapshots. How valuable that testing is and how the issue could be mitigated via best practices are where I think discussion is valuable. (Note, that abandoning tarballs also starts to impact users as well. In a vanilla tarball scenario it's easy to see what the distro specific changes to an upstream release are. In a snapshot scenario, the base from which you're working can be different as well. This makes it harder for upstream and the user to work together as they don't have a common understanding of what they're running. A user can quickly verify whether there are local patches to an upstream tarball. They will have more difficulty figuring out whether the snapshot included in the package is exactly equivalent to upstream's release or has changes in a relevant area.) -Toshio signature.asc Description: OpenPGP digital signature ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: Dealing with autotools
also sprach Toshio Kuratomi a.bad...@gmail.com [2009.05.09.2006 +0200]: 1) Is source url canonical? 2) Download tarball from source url. 3) sha1sum tarball just downloaded matches with sha1sum tarball used to build package. (If you're the maintainer, you don't have to do step 3) you *should* though, and insist on a trust path to the author, or else all I ever have to do to harm all Fedora people is DNS-poison a Fedora maintainer's connection. 4) Pull the latest source from the repo 5) untar the tarball 6) Diff between the source repo and the tarball 7) For the differences between the source repo and tarball check that: * the differences are due to a file generated in the creation of the tarball (like configure or Makefile.in) * files that won't matter to the build (upstream has a HOW_TO_RELEASE file in the repo that isn't in the tarball) * other things that are more subtle :-( (permissions on files, versions substituted into files at tarball creation time, etc) Yes; or make sure that upstream understands to build the tarball from a tag, and not the other way around: tag after the tarball was built. Yes. One of your assumptions is wrong. You limit the other people to those folks who rebuild their software for every upstream release. In fact, distributions are not going to all switch to a snapshot model immediately (some may not do so until upstreams stop releasing tarballs.) So you could have the set of Debian and Ubuntu users using a snapshot while Fedora, Red Hat, Gentoo, NetBSD, Freebsd, MacOS-fink, Solaris, OpenSuSE, (et al) using the tarball. Even if we get a significant portion of distros basing off of snapshots instead of release tarballs, we still have the problem of which snapshot is being used. It's nice to assume that people will only use a tag representing a release but I doubt that that's what will happen in practice. Working with upstream's repository directly makes it easy to base your package against something slightly newer than the release that just picks up this one tiny bugfix and oh, this other small feature, and... So yes, I think the base of testing of a single tarball now is much higher than what we'll see collectively even if we all go to snapshots. I don't have anything to say against that, except... How valuable that testing is and how the issue could be mitigated via best practices are where I think discussion is valuable. ... precisely. (Note, that abandoning tarballs also starts to impact users as well. In a vanilla tarball scenario it's easy to see what the distro specific changes to an upstream release are. In a snapshot scenario, the base from which you're working can be different as well. This makes it harder for upstream and the user to work together as they don't have a common understanding of what they're running. Not if VCS becomes even more ubiquitous (read: even available to the user) as it is right now. Thanks for your valuable input! -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems dies ist eine manuell generierte email. sie beinhaltet tippfehler und ist auch ohne großbuchstaben gültig. digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: Dealing with autotools
also sprach Russ Allbery r...@stanford.edu [2009.03.10.2247 +0100]: When packaging, I'm undecided on these two options: 1. Build-depend on automake and let it rebuilt itself at 'make' time Definitely the right solution IMO. This is what I do with all of my packages. Wasn't this heavily frowned upon in Debian for many years? I just read again /usr/share/doc/autotools-dev/README.Debian (unfortunately, I cannot find a VCS link to that file, so I put it up here: [0]), and it contains a lot of valuable information on the issue. Maybe the most important message from it is that the use of patch systems (and this includes vcs-pkg, at least in spirit) requires one to do either - build-depend on automake/autoconf and make those steps part of the build process - work with upstream to fix their build systems so they can be tweaked for distros with command-line options instead of patches. To me, it sounds like those are exactly our goals, so it seems as if build-depending on the autotools is the right way forward. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems in a country where the sole employer is the state, opposition means death by slow starvation. the old principle: who does not work shall not eat, has been replaced by a new one: who does not obey shall not eat. -- leon trotsky, 1937 digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: Dealing with autotools
On Wed, 2009-04-15 at 12:07 +0200, martin f krafft wrote: also sprach Russ Allbery r...@stanford.edu [2009.03.10.2247 +0100]: When packaging, I'm undecided on these two options: 1. Build-depend on automake and let it rebuilt itself at 'make' time Definitely the right solution IMO. This is what I do with all of my packages. Wasn't this heavily frowned upon in Debian for many years? Opinions have varied. I just read again /usr/share/doc/autotools-dev/README.Debian (unfortunately, I cannot find a VCS link to that file, so I put it up here: [0]), and it contains a lot of valuable information on the issue. Maybe the most important message from it is that the use of patch systems (and this includes vcs-pkg, at least in spirit) requires one to do either - build-depend on automake/autoconf and make those steps part of the build process - work with upstream to fix their build systems so they can be tweaked for distros with command-line options instead of patches. Or both :). To me, it sounds like those are exactly our goals, so it seems as if build-depending on the autotools is the right way forward. Absolutely; not build-deping on autotools is a fundamental mistake IMO: it makes packages bigger (you have to carry a configure script delta), harder to review (generated content is in the diff). -Rob signature.asc Description: This is a digitally signed message part ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: Dealing with autotools
On Wed, Apr 15, 2009, Robert Collins wrote: Wasn't this heavily frowned upon in Debian for many years? Opinions have varied. And still do... Absolutely; not build-deping on autotools is a fundamental mistake IMO: it makes packages bigger (you have to carry a configure script delta), harder to review (generated content is in the diff). I find that running the autotools during build is fragile over time. It can break in subtle ways with new autotools versions. Most people don't understand autotools enough to do the right thing. Most packages running autotools during build will call automake, aclocal, autoconf in weird orders or lacking some additional commands which their packages need -- instead of autoreconf, which might not even be enough when you're using things like intltool or glib-gettext. Also, running autotools at runtime requires you to build-depend on all tools needed by the upstream maintainer instead of just the libs you need to build the features you care about; often people will miss some bdeps as a result (typically when upstream doesn't ship some m4 macros). In all cases, this is not black and white; I would still recommend that people who aren't versed in autotools just autoreconf into a patch and make sure that patched tree works well. -- Loïc Minier ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: Dealing with autotools
On Wed, Apr 15 2009, Loïc Minier wrote: On Wed, Apr 15, 2009, Robert Collins wrote: Wasn't this heavily frowned upon in Debian for many years? Opinions have varied. And still do... Absolutely; not build-deping on autotools is a fundamental mistake IMO: it makes packages bigger (you have to carry a configure script delta), harder to review (generated content is in the diff). I find that running the autotools during build is fragile over time. In my experience, while that used to be true, it has not been the case for some time now. It can break in subtle ways with new autotools versions. Sure. But that hasn't happened to me in a couple of years now, and the threat of breakage has to be measured against the advantages of a better build fit on a user's machine. I don't just package for myself, or Debian: the software is put together for the end user to build themselves (isn't that what all this free software all about?), so running auto-tools on the machine it is to be used on has benefits. Most people don't understand autotools enough to do the right thing. I hope developers are not in that number. Most packages running autotools during build will call automake, aclocal, autoconf in weird orders or lacking some additional commands which their packages need -- instead of autoreconf, which might not even be enough when you're using things like intltool or glib-gettext. In the configure phase of my packages, I call the tools in the proper order, instead of lettting it be random chance, so this is mostly irrelevant. People can be taught to do things propoerly in the configure target. Also, running autotools at runtime requires you to build-depend on all tools needed by the upstream maintainer instead of just the libs you need to build the features you care about; often people will miss some bdeps as a result (typically when upstream doesn't ship some m4 macros). Being careful about build dependencies is one of the things developers do: or, at least, competent developers. There is not guarantee that you will not miss build dependencies even on your development box, you might not have all the things installed. I generally study the configure file, and see what configure is probing for. And then I look to see if the code woul take advantage of the things being probed for. Then I build in a build virtual machine, and compare with a similar build on my development box, and compare. I would think this would be standard package maintainer activity. In all cases, this is not black and white; I would still recommend that people who aren't versed in autotools just autoreconf into a patch and make sure that patched tree works well. I used to believe that, until around 2005-2006. Since then, I have done autotools at package build time, and I would strongly recommend my peers to do the same. manoj -- I do not fear computers... I fear the lack of them. Isaac Asimov Manoj Srivastava sriva...@acm.org http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Dealing with autotools
Hello, I am trying to find a good workflow to maintain a package in git. The package requires several patches to its configure.ac and Makefile.am files, and upstream is generally too overworked to be able to review and integreate patches. I also want to stick to existing tools like git-import-dsc, git-import-orig, git-buildpackage and pristine-tar as much as possible. My main problem is that after importing upstream's sources, I end up with the various autotools fluff (./configure, Makefile.in and so on) committed in. When I change autotools files in topic branches, and test if it works, then the fluff gets updated as well. If I commit everything, then at the point of merging the various topic branches together, or at the point of importing a new upstream version, I risk ending up with conflicts all over the place. The way I figured so far is this: 1. git-import-dsc --pristine-tar 2. branch off upstream and create a topic branch 3. do my changes and test them 4. commit only the files that I have changed, and not the files that autotools has regenerated. This could be a bit cumbersome, but it can be automated with something like: git checkout aclocal.m4 configure `git ls-files -c |grep .in\$` 5. I do not merge topic branches into the debian branch, but I collect them as quilt patches In this way, I can easily merge a new upstream version into the topic branches, and git diff upstream tbranch1 will always give me a clean patch. I get to test all topic branches separately, and they can even be merged cleanly into a temporary branch to test if they work together. The point of the topic branches becomes to maintain the patch as upstream is updated. This sounds an awful lot like topgit, but I have not explored it enough to know whether I'm just redoing what it does. I am now tempted to maintain a FIXME.branchname file per branch, where I keep notes of why the patch is there, what's missing for upstream to integrate it, and so on. When packaging, I'm undecided on these two options: 1. Build-depend on automake and let it rebuilt itself at 'make' time 2. git checkout master -b temp quilt push -a autoreconf -if git show debian/patches/autotools.diff # Ensure that autotools.diff is the last patch in the series git checkout master git branch -D temp Option 2 sounds quite nice, but wow, 1476264 bytes of patch. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini enr...@debian.org signature.asc Description: Digital signature ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: Dealing with autotools
Enrico Zini enr...@enricozini.org writes: The way I figured so far is this: 1. git-import-dsc --pristine-tar 2. branch off upstream and create a topic branch 3. do my changes and test them 4. commit only the files that I have changed, and not the files that autotools has regenerated. This could be a bit cumbersome, but it can be automated with something like: git checkout aclocal.m4 configure `git ls-files -c |grep .in\$` I think if you add a .gitignore file on topic branches that modify the Autoconf files. I think that will do the same thing for you. When packaging, I'm undecided on these two options: 1. Build-depend on automake and let it rebuilt itself at 'make' time Definitely the right solution IMO. This is what I do with all of my packages. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
