On Sun, Jan 10, 2010 at 4:34 PM, Pavel Heimlich <tropikhajma at gmail.com>
wrote:
>> Now it does make the logic of the spec files slightly
>> more complicated, using
>> logic to enable patches, but I have lots of examples
>> that work.
>
> hmm, you mean like
> %if version is <1.2.3
> use patch1
> %elif version is >=1.2.3 and <= 1.2.5
> use patch2
> %else
> use patch3
> %endif
You had something like that in base-boost.spec. There are
ways to get around things like that. If using patch %{src_name}/%{src_ver}
subdirs, you could have those patches that aren't necessary basically
generated files /tmp for the purposes of not changing the logic.
Look at what I did with the last boost patch. Also, for a little more
complication (which I'm inclined to avoid) look at some of the
other FOSS packages where I make use of that. cups is a good
example.
As we've discussed on #kde4-solaris, I think that kde patches themselves
probably should either stay in patches or move to patches/%{src_name}
with links up to patches until the relative patchdir "patch" is formalized
in pkgtool.
> that'd bring way too much complexity and would be unmanageable IMO.
I've been working around it very nicely with the FOSS package. But as
mentioned, we're not changing FOSS packages every couple of weeks
as we come up on a release.
> We can have the separation of patches into directories, it has other benefits
> as well, but to go back a version one would just figure the best revision of
> the spec and use Mercurial's forces to revert to it.
I agree that for the kde code, this makes sense. the overhead of managing
the churn of revisions is a bit much.
> Can we use tags to make it easy to find version changes?
> http://mercurial.selenic.com/wiki/Tag
Probably.
Ben
