patch naming scheme.

[Thorsten Leemhuis]

On 11.10.2008 02:37, Dave Jones wrote:
> On Fri, Oct 10, 2008 at 05:55:50PM -0400, Jarod Wilson wrote:
>  > On Friday 10 October 2008 17:27:00 Chris Snook wrote:
>  > > Dave Jones wrote:
>  > > > For a while, diffs in the Fedora kernel have followed the form
>  > > > linux-2.6-*.patch
>  > > > Then, we started seeing some git snapshots show up as
>  > > > git-*.diff
>  > > > and lately, everything seems to have gone bananas, with no
>  > > > particular scheme at all..
>  > > > nvidia-agp.patch, percpu_counter_sum_cleanup.patch, xfs-barrier-fix.patch
>  > > > etc etc.
>  > > > Maybe I'm being overly anal.  The linux-2.6- prefix is kind of pointless
>  > > > (given that duh, they're all going to be against Linux 2.6), but it
>  > > > does group things nicely in an ls output if nothing else.
>  > > > So, what are peoples thoughts on this?
>  > > If we'd prefix them with the source package name, in this case "kernel", it
>  > > would make it a lot easier to find things in /usr/src/redhat/SOURCES when
>  > > we've got SRPMs from different packages installed.  We should probably
>  > > avoid using names that refer to a specific upstream version, because the
>  > > name becomes misleading once we rebase.  When there's a suitable upstream
>  > > patch name, like the names Andrew Morton uses in -mm, we should probably
>  > > use those (perhaps prepended with kernel-) to make it clear what it
>  > > corresponds to upstream.
>  > Yeah, I'd be happy with <pkgname>-<tree id>-<description>.patch, omitting the 
>  > tree id portion if there isn't one, or some variant thereof. Being able to do 
>  > an 'ls kernel*.patch' is definitely useful.
> kernel-* is sacred.  Tab completion ftw. :)

Just a note: Isn't there some rule or suggestion hidden in our 
guidelines somewhere(¹) that suggests to prefix all patches for package 
"foo" with "foo-" (or simply "%{name}-" in practice)? That should avoid 
that files from one srpm on install accidentally replace files that are 
were installed earlier by a different srpm.

Cu
knurd

(¹) I could not find it, but there are people that know those long and 
complicated guidelines way better than I do