> > Proposal:
> > - use name of source which patch is apply to. Patch should not
> > fix files from different source.
> > - if is not possible use name of source, use name of package
> > instead.
>
> Well, whatever, I prefer to stick to the package name.
> Don't think it's really critical, but it must be one of them (source
> name or package name).
> Obviously, when there are several original source tarballs, the "name"
> prefix of the patch should be the name of the source tarball it applies to.
I see, but i still think that name of source is better. It is not critical
with one source package, though.
>
> > 1.2.2 Number
> > ------------------
> > Number as version of source or package is heavily used in patch name.
>
> I never do, I find it rather annoying and misleading.
> Before building a new version of a package, I check whether the patches
> still apply. If they do, fine, if they don't, I just port them but keep
> the [patch] filename.
That is exactly point for numbering patches. When patch is numbered, you
should investigate if patch is not allready in upstream. All "reasonable"
patches should go to upstream.
> > is updated to new version, all patch had to be updated. In SUSE, there
> > are many packages which contains patch, which are not sent to upstream,
> > because they fix SUSE specific problems.
> > Proposal:
> > - use no number at all for patch which are not meant to be send
> > in upstream (SUSE specific, temporary distribution dependent fix ....)
> > - use number for patch which are only for this version of package
> > (source), this patch should be sent to upstream. This number should be
> > changed when updating to new version if we still expect this patch to be
> > accepted by upstream. If no, number should be removed from this patch.
>
> I won't stick to this one, that's just too complicated, too many if's.
>
> And using a version number in the patch filename has a drawback: when
> you have to port the patch because the sources don't match, you have to
> rename the patch file, e.g. from moo-1.2.3-fix-foobar.patch to
> moo-1.3.8-fix-foobar.patch
> The problem with that is SCM, as you can't clearly see that you've
> modified a patch in the change set. It's not as bad with SVN, as you can
> "svn move" a file to rename it, but it's still a bit tedious. And with
> CVS, you just don't see it at all and end up with files in Attic.
Patch numbering have some drawbacks, everything have. But i still think that
is better to do some work when updating, that do a lot of work searching
every patch what to do.
The if`s are really sample actually. If this fix is "SUSE only" (menu, file
position, icons ...) no number.
If patch have number, it should be send to upstream..
> > - there are patch which fix problem which is caused by another
> > part of system ( broken library, autobuild....). Patch name should
> > reflect this. We propose to use buildfix/temporaryfix/runfix for such
> > patch. This patch should be removed as soon as possible (probably when
> > updating to new version)
> > buildfix - if this package could be builded, this patch
> > could be safely removed.
> > runfix - if this package could be runed without this
> > patch, this patch could be safely removed.
> > temporaryfix - all other temporary fix.
>
> How is a fix "temporary" ? As long as it isn't fixed upstream, a patch
> is necessary, doesn't matter whether it's for the build system or for
> real sources.
There are cases when package is broken because of error in other package(s).
This is really special case. Such a fix is neither meant to be sent to
upstream, nor stay with package for long time.
> > Comment should be also used, if patch is used differently than normal.
> > e.g. (blender)
> > Patch1: po.patch
>
> ^^^^^^^^^^^^^^^^^^^^^^^^
> <nitpicking>
> Hey, that one doesn't comply to your proposal ;D
> Should be %{name}-po-fix-typos.patch
> </nitpicking>
You are right. This is "old" patch. Before proposal ;-)
>
> > Patch2: blender-home-to-datadir.patch
> > # patch is applied only on x86-64
> > Patch5: Scons.patch [...]
>
> (same nitpicking as above ;))
Same as above.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
