Re: A standard patch rule for our rules
Ben Finney ben+deb...@benfinney.id.au wrote: [...] It seems to me that the whole point of adding ‘patch’ as a (phony) target is to allow a dependency on that target, [...] Hello, Being used as dependencies of non-phony targets is the one thing phony targets are not useful for. A phony dependency is always out of date and will cause rerunning of the depending target. (I am pretty sure you knew that, and I am just misparsing.) I do not know what is wrong with having patch a phony target, though, phony target are fine for direct invocation (debian/rules patch) and that seems to be whole point of the respective entry in policy. cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
A standard patch rule for our rules
A ``patch'' rule for debian/rules there should always be for I'd like to easily apply patches created by me Don't worry I don't think of anything too hard a simple standarization will ease my heart Today ``debian/rules build'' is always a good match but there's no mandatory ``debian/rules patch'' Is the ``build'' rule mandatory? I don't even know it seems to work for most packages, though Patches, it seems, are for ``configure'' rule to apply but I want to make a script and I think it won't fly That script I think of will install my own patches to any installable package, from zopes to apaches Configures can change too much like config.h files and such There should be one and only patch rule and then I'll be able to build my tool -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: A standard patch rule for our rules
Rafael Almeida almeida...@gmail.com writes: A ``patch'' rule for debian/rules there should always be for I'd like to easily apply patches created by me Don't worry I don't think of anything too hard a simple standarization will ease my heart Today ``debian/rules build'' is always a good match but there's no mandatory ``debian/rules patch'' Is the ``build'' rule mandatory? I don't even know it seems to work for most packages, though Debian policy describes all the required targets and some optional ones. Patches, it seems, are for ``configure'' rule to apply but I want to make a script and I think it won't fly That script I think of will install my own patches to any installable package, from zopes to apaches Configures can change too much like config.h files and such There should be one and only patch rule and then I'll be able to build my tool man dpkg-source Format: 3.0 (quilt) A source package in this format contains at least an original tarball (.orig.tar.ext where ext can be gz, bz2 and lzma) and a debian tarball (.debian.tar.ext). It can also contain additional original tarballs (.orig-component.tar.ext). component can only contain alphanumeric characters and dashes (-). ... Behold the future is, aeh, soon. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: A standard patch rule for our rules
Nice poem :) -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: A standard patch rule for our rules
Rafael Almeida almeida...@gmail.com wrote: A ``patch'' rule for debian/rules there should always be for I'd like to easily apply patches created by me Don't worry I don't think of anything too hard a simple standarization will ease my heart Today ``debian/rules build'' is always a good match but there's no mandatory ``debian/rules patch'' Is the ``build'' rule mandatory? I don't even know it seems to work for most packages, though [...] patch indeded is the standard way nowadays. See policy 4.9. cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: A standard patch rule for our rules
On Wed, Jul 01, 2009 at 07:43:37PM +0200, Andreas Metzler wrote: Rafael Almeida almeida...@gmail.com wrote: A ``patch'' rule for debian/rules there should always be for I'd like to easily apply patches created by me Don't worry I don't think of anything too hard a simple standarization will ease my heart Today ``debian/rules build'' is always a good match but there's no mandatory ``debian/rules patch'' Is the ``build'' rule mandatory? I don't even know it seems to work for most packages, though [...] patch indeded is the standard way nowadays. See policy 4.9. I think you mean “recommended”, although not using that could be a reason to have a README.source explaining how the package is handled. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@debian.org signature.asc Description: Digital signature
Re: A standard patch rule for our rules
Le Wed, Jul 01, 2009 at 07:43:37PM +0200, Andreas Metzler a écrit : Rafael Almeida almeida...@gmail.com wrote: A ``patch'' rule for debian/rules there should always be for I'd like to easily apply patches created by me Don't worry I don't think of anything too hard a simple standarization will ease my heart Today ``debian/rules build'' is always a good match but there's no mandatory ``debian/rules patch'' Is the ``build'' rule mandatory? I don't even know it seems to work for most packages, though [...] patch indeded is the standard way nowadays. See policy 4.9. Unfortunately, it seems that with quilt, it is better ot use $(QUILT_STAMPFN) in order to avoid a target to become phony. I do not know for other systems. I just updated http://wiki.debian.org/debian/patches to mention this fact. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: A standard patch rule for our rules
Charles Plessy ple...@debian.org writes: Le Wed, Jul 01, 2009 at 07:43:37PM +0200, Andreas Metzler a écrit : patch indeded is the standard way nowadays. See policy 4.9. Unfortunately, it seems that with quilt, it is better ot use $(QUILT_STAMPFN) in order to avoid a target to become phony. What's wrong with having a phony target? We already have many of them, and a standard way of dealing with them: as dependencies of the ‘.PHONY’ target. It seems to me that the whole point of adding ‘patch’ as a (phony) target is to allow a dependency on that target, instead of something patch-system-specific. What is your reasoning for wanting to diverge from that? -- \ “Two possibilities exist: Either we are alone in the Universe | `\ or we are not. Both are equally terrifying.” —Arthur C. Clarke, | _o__) 1999 | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: A standard patch rule for our rules
Ben Finney ben+deb...@benfinney.id.au writes: Charles Plessy ple...@debian.org writes: Unfortunately, it seems that with quilt, it is better ot use $(QUILT_STAMPFN) in order to avoid a target to become phony. What's wrong with having a phony target? We already have many of them, and a standard way of dealing with them: as dependencies of the ‘.PHONY’ target. It seems to me that the whole point of adding ‘patch’ as a (phony) target is to allow a dependency on that target, instead of something patch-system-specific. What is your reasoning for wanting to diverge from that? I think Charles may be referring to the need to use $(QUILT_STAMPFN) rather than patch as a dependency of a build-stamp target, since otherwise the dependency on patch forces build-stamp to be always considered out of date even if the stamp file is up-to-date. This has caused problems for a few packages where the build target was run repeatedly in ways that it wasn't intended to. Depending on $(QUILT_STAMPFN) instead is more reliable. I'm not entirely sure how that relates to the topic of conversation in this thread, though. It doesn't affect the presence of the patch target in debian/rules. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
