[gentoo-dev] Re: please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}
Marijn Schouten (hkBst) hk...@gentoo.org 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
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 mrn...@gentoo.org 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}
On 3/23/09 1:44 AM, Jeremy Olexa wrote: Alin Năstac wrote: snip 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
[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 mrn...@gentoo.org 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}
Ryan Hill wrote:
Alin Năstac mrn...@gentoo.org 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}-pre-bump-version
- 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
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}
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
[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 grob...@gentoo.org 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
[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 mounir.lamo...@gmail.com wrote:
On Sun, Mar 22, 2009 at 1:18 PM, Ulrich Mueller u...@gentoo.org
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
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
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 mrn...@gentoo.org 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
[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 mrn...@gentoo.org 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}
Alin Năstac wrote: snip 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
