Re: Build systems (was Re: An alarming trend (no it's not flaimbait.))
Adam Heath writes: > On 27 Dec 2001, Tollef Fog Heen wrote: > > > * Adam Heath > > > > | dbs(doogie build system, debian build system) > > | > > | See autofs, apache, x(contains a pre-alpha version of dbs). > > | > > | Do NOT see glibc, gcc. Those use dpatch, which was around before dbs. > > Dbs > > | has a larger following(but well under 100 packages use it). > > > > What are the differences between DBS and dpatch, and why should I > > choose one or the other? > > dpatch offers no patch ordering. dbs does it does have patch ordering. the order is determined by the debian_patches macro. > Also, an unreleased dbs supports patch dependencies. It was a quick simple > modification to dbs to get it to support this. Dbs uses a single script to > apply all patches, which makes adding features easy. dpatch turns each patch > into a script, which means the scriptage needs to be updated by hand when a > new feature is needed. yes, the rationale is to run commands after the patch was applied (mostly autoconf to regenerate configure) > Neither dbs nor dpatch are documented. found this out while looking at dbs...
Re: Build systems (was Re: An alarming trend (no it's not flaimbait.))
On Thu, 27 Dec 2001, Colin Watson wrote: > What do you think of the perl build system? It has the maintainer run > the patch and unpatch targets manually as necessary. Providing the > maintainer's happy with this extra step, the only obvious disadvantage > is that the diff almost doubles in size. I'm considering something like > this for groff, unless the new dpkg-source will be arriving soon. I've never heard of it, so I have no comments about it. I don't like the doubling of the diff that this will cause. On the state of that new dpkg-source: It currently can extract and create old format(version 1.0) source archives. It can extract new format(version 2.0, multi diff/tar, zip/bzip support as well). Building of the new format is a little more complex. It may not make it into dpkg 1.10(which, roughly, may be released sometime between March and May, after woody has been fully frozen for quite a bit(this is not an official release schedule for dpkg)). I may have it all working by next June to August. I've given plenty of time here, hopefully I can keep the schedule.
Re: Build systems (was Re: An alarming trend (no it's not flaimbait.))
On Thu, Dec 27, 2001 at 05:42:52PM -0600, Adam Heath wrote: > You should use dbs or dpatch if you end up having lots of patches > against upstream, and want to maintain them as short, small, separate > patches, instead of one single huge debian diff.gz. My main beefs with both DBS and dpatch are probably held by several others: the tarball-in-a-tarball business (aesthetic) and the fact that you have to perform extra steps after 'dpkg-source -x' which vary from package to package before you can see the source that's actually built. I realize you may not see either of these as problems. What do you think of the perl build system? It has the maintainer run the patch and unpatch targets manually as necessary. Providing the maintainer's happy with this extra step, the only obvious disadvantage is that the diff almost doubles in size. I'm considering something like this for groff, unless the new dpkg-source will be arriving soon. My rationale for preferring the perl system is that I'd rather have the maintainer perform an extra step he/she's familiar with than have all the users who download the source perform an extra step they're unfamiliar with. Of course, it gets less practical as the .diff.gz grows. -- Colin Watson [EMAIL PROTECTED]
Re: Build systems (was Re: An alarming trend (no it's not flaimbait.))
On 27 Dec 2001, Tollef Fog Heen wrote: > * Adam Heath > > | dbs(doogie build system, debian build system) > | > | See autofs, apache, x(contains a pre-alpha version of dbs). > | > | Do NOT see glibc, gcc. Those use dpatch, which was around before dbs. Dbs > | has a larger following(but well under 100 packages use it). > > What are the differences between DBS and dpatch, and why should I > choose one or the other? dpatch offers no patch ordering. dbs does dpatch offers no command to generate a diff automatically. dbs does Also, an unreleased dbs supports patch dependencies. It was a quick simple modification to dbs to get it to support this. Dbs uses a single script to apply all patches, which makes adding features easy. dpatch turns each patch into a script, which means the scriptage needs to be updated by hand when a new feature is needed. Neither dbs nor dpatch are documented. You should use dbs or dpatch if you end up having lots of patches against upstream, and want to maintain them as short, small, separate patches, instead of one single huge debian diff.gz.
