[gentoo-dev] Re: please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}
"Marijn Schouten (hkBst)" posted 49c8d6ee.3070...@gentoo.org, excerpted below, on Tue, 24 Mar 2009 13:49:50 +0100: > Lastly I prefer to have the source changes right there in the ebuild > when they are not too elaborate and patches don't allow that. The preference makes sense, but the statement based on it, that patches don't allow putting the change in the ebuild, doesn't. I've used here document based patches in my own bash scripts to good effect so I know it works, and if it's working in my bash scripts, it's going to work in bash script based ebuilds as well. The only reason patches would need to be file based would be convenience, and as soon as it's an inconvenience, with the convenience being having them in the ebuild itself, here document based patches to the rescue! =:^) That "sed", "said" (ha! =:^) does have certain advantages as you pointed out, when a specific string change is desired, regardless of context, which may well change between versions. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
[gentoo-dev] Re: please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}
On Mon, 23 Mar 2009 11:51:28 +0100 Fabian Groffen wrote: > On 23-03-2009 11:41:08 +0100, Sebastian Pipping wrote: > > People split into three groups: > > > > - Friends of ${P}-fix-issue.patch naming > > - Friends of ${PN}-fix-issue.patch naming > > - Friends of ${PN}-1.2.3-fix-issue.patch naming > > > > Qualities > > [snip] > > I think what's missing is the following observation: > > ${PN}-fix-issue.patch naming is bad if you patch code that is (likely) > to change in newer releases. This is almost always the case. > Ultimate example, patch something in ffmpeg or mplayer, and the next > snapshot will break the patch. (i.e. doesn't apply any more.) Using > ${PN}-fix-issue.patch in this case gets you into > ${PN}-fix-issue-2.patch, which IMO is ugly. > > If patches are named this way, they probably fall in the case where > the code it patches is unlikely to change. (assumption) > > > Possible solutions > > > > - *Communicating* your likes to all co-maintainers > > in hope the will respect and remember your agreement > > > > - Add a related local comment (*documenting*) to ebuilds > > and expect other developers to act accordingly on a bump > > probably best solution > > > - Making a GLEP *enforcing* on of these and make people > > vote on which > > very bad one. > > Thanks for this. And apologies to Alin. I was in a very bad mood yesterday. -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}
Fabian Groffen wrote: > I think what's missing is the following observation: > > ${PN}-fix-issue.patch naming is bad if you patch code that is (likely) > to change in newer releases. This is almost always the case. Ultimate > example, patch something in ffmpeg or mplayer, and the next snapshot > will break the patch. (i.e. doesn't apply any more.) Using > ${PN}-fix-issue.patch in this case gets you into > ${PN}-fix-issue-2.patch, which IMO is ugly. > > If patches are named this way, they probably fall in the case where the > code it patches is unlikely to change. (assumption) Good point. In that case the patch "revision" 2 in "${PN}-fix-issue-2.patch" actually stands for "${PN}-fix-issue-1.2.4.patch" where "1.2.4" is the version of the new package. Therefor we effectively ${PV} from the begining to the end. So a conlusion from this would be that ${PN} is not suited for all ebuilds and therefore should not be standard alone if at all? Sebastian
Re: [gentoo-dev] Re: please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}
On 23-03-2009 11:41:08 +0100, Sebastian Pipping wrote: > People split into three groups: > > - Friends of ${P}-fix-issue.patch naming > - Friends of ${PN}-fix-issue.patch naming > - Friends of ${PN}-1.2.3-fix-issue.patch naming > > Qualities [snip] I think what's missing is the following observation: ${PN}-fix-issue.patch naming is bad if you patch code that is (likely) to change in newer releases. This is almost always the case. Ultimate example, patch something in ffmpeg or mplayer, and the next snapshot will break the patch. (i.e. doesn't apply any more.) Using ${PN}-fix-issue.patch in this case gets you into ${PN}-fix-issue-2.patch, which IMO is ugly. If patches are named this way, they probably fall in the case where the code it patches is unlikely to change. (assumption) > Possible solutions > > - *Communicating* your likes to all co-maintainers > in hope the will respect and remember your agreement > > - Add a related local comment (*documenting*) to ebuilds > and expect other developers to act accordingly on a bump probably best solution > - Making a GLEP *enforcing* on of these and make people > vote on which very bad one. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] Re: please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}
Ryan Hill wrote: > Alin Năstac wrote: > >> I suppose what everyone does in their part of the tree is their >> business, but a small subset of packages I maintain have other >> maintainers as well. It is annoying to see rules you assume being >> respected on your ebuilds being broken at every bump made by others. > > I'm sure they're just as annoyed by your bizarre take on patch version > numbering as you are with theirs. ;) Let me try summarizing and dissecting this issue. Please correct and extend where necessary. Bike shedding versus "real issue" - Issue itself might not be earth-shaking - Repeated frustration can become a problem - Frustration with this is present (me included) - Happy developers stay much longer People split into three groups: - Friends of ${P}-fix-issue.patch naming - Friends of ${PN}-fix-issue.patch naming - Friends of ${PN}-1.2.3-fix-issue.patch naming Qualities - ${P} i.e. ${PN}-${PV} - On version bump either .. - Constant on version bump - Several same-content patch files across ebuilds - .. or .. - Change to ${PN}- - Single patch file across ebuilds - Maybe helps reminding most patches should move from downstream to upstream? - 1:1 patch-ebuild relation (see below) - ${PN} - Constant on version bump - Single patch file across ebuilds - Several ebuilds need to be inspected to find out if a patch file is still used - 1:1 patch-ebuild relation (see below) - ${PN}-1.2.3 - Constant on version bump - Single patch file across ebuilds - Several ebuilds need to be inspected to find out if a patch file is still used - <=${PV} values indicate things: either - the patch is downstream only - upstream has not applied it - 1:n patch-ebuild relation (inverse qualities of 1:1 patch-ebuild relation, see below) - 1:1 patch-ebuild relation - Finding out if a patch is still needed is trivial - In-place patch updates possible without affecting other ebuilds - 1:1 benefits only apply if ${P} is used consistently in the whole tree Possible solutions - *Communicating* your likes to all co-maintainers in hope the will respect and remember your agreement - Add a related local comment (*documenting*) to ebuilds and expect other developers to act accordingly on a bump - Making a GLEP *enforcing* on of these and make people vote on which Sebastian
[gentoo-dev] Re: please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}
On Mon, 23 Mar 2009 09:04:32 +0100 Alin Năstac wrote: > I suppose what everyone does in their part of the tree is their > business, but a small subset of packages I maintain have other > maintainers as well. It is annoying to see rules you assume being > respected on your ebuilds being broken at every bump made by others. I'm sure they're just as annoyed by your bizarre take on patch version numbering as you are with theirs. ;) -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}
On 3/23/09 1:44 AM, Jeremy Olexa wrote: > Alin Năstac wrote: > >> Fine, then remove $PV from patch name and use it in any ebuild version >> you want. Or just decouple the patch version from the ebuild version >> (foo-bar-r1.patch sounds OK to me). >> > > What exactly is your problem that you are trying to solve here? > Posting to the community to stop doing something without providing > reasons to stop is not going to go anywhere. I like having the PV in > the patch name..so, you haven't convinced me. > IMO prefixing a patch name with $P creates the perception that the patch is used only from ebuild version $PV. Apparently we do not agree on this so there is not much more I can tell to convince others. I suppose what everyone does in their part of the tree is their business, but a small subset of packages I maintain have other maintainers as well. It is annoying to see rules you assume being respected on your ebuilds being broken at every bump made by others. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}
On 3/23/09 1:42 AM, Ryan Hill wrote: > On Mon, 23 Mar 2009 01:19:26 +0100 > Alin Năstac wrote: > > >> Fine, then remove $PV from patch name and use it in any ebuild version >> you want. Or just decouple the patch version from the ebuild version >> (foo-bar-r1.patch sounds OK to me). >> > > No. It's done this way for a reason. > > I saw your reason about wanting to know the package version for which the patch was created and I cannot see any reason for knowing that other than submitting the patch to upstream. Somehow I doubt upstream is interested in patches for version x.y.1 when the current version is x.y.10. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}
Alin Năstac wrote: Fine, then remove $PV from patch name and use it in any ebuild version you want. Or just decouple the patch version from the ebuild version (foo-bar-r1.patch sounds OK to me). What exactly is your problem that you are trying to solve here? Posting to the community to stop doing something without providing reasons to stop is not going to go anywhere. I like having the PV in the patch name..so, you haven't convinced me. -Jeremy
[gentoo-dev] Re: please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}
On Mon, 23 Mar 2009 01:19:26 +0100 Alin Năstac wrote: > Fine, then remove $PV from patch name and use it in any ebuild version > you want. Or just decouple the patch version from the ebuild version > (foo-bar-r1.patch sounds OK to me). No. It's done this way for a reason. -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}
On 3/22/09 11:47 PM, Ryan Hill wrote: > On Sun, 22 Mar 2009 17:50:26 +0100 > Alin Năstac wrote: > > >> Please do not apply patches that have ${P} prefix in other ebuild >> versions than ${PV}. >> Is that hard to create a new patch with a proper name? >> > > Um, why? > > I'm not having six identical patches with different version numbers in > FILESDIR. > > Fine, then remove $PV from patch name and use it in any ebuild version you want. Or just decouple the patch version from the ebuild version (foo-bar-r1.patch sounds OK to me). signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}
Ryan Hill wrote: >> Please do not apply patches that have ${P} prefix in other ebuild >> versions than ${PV}. >> Is that hard to create a new patch with a proper name? > > Um, why? > > I'm not having six identical patches with different version numbers in > FILESDIR. Good point. Sebastian
[gentoo-dev] Re: please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}
On Sun, 22 Mar 2009 13:24:26 -0400 Mounir Lamouri wrote: > On Sun, Mar 22, 2009 at 1:18 PM, Ulrich Mueller > wrote: > >> On Sun, 22 Mar 2009, mrness wrote: > > > >> Please do not apply patches that have ${P} prefix in other ebuild > >> versions than ${PV}. > >> Is that hard to create a new patch with a proper name? > > > > And multiply number and total size of files in ${FILESDIR}? > > > > Or just rename it ${PN}-bar.patch instead of ${P}-bar.patch if it is a > patch for more than one ebuild version. And when the patch has to be changed? ${PN}-foo-2.patch? The PV in the patch name indicates what version the patch was made for. This can be useful info, if just for judging how bad you are at sending patches upstream. ;) -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-dev] Re: please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}
On Sun, 22 Mar 2009 17:50:26 +0100 Alin Năstac wrote: > Please do not apply patches that have ${P} prefix in other ebuild > versions than ${PV}. > Is that hard to create a new patch with a proper name? Um, why? I'm not having six identical patches with different version numbers in FILESDIR. -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature