On Sat, Jan 9, 2010 at 5:34 PM, Adriaan de Groot <groot at kde.org> wrote:
> On Friday 08 January 2010 18:34:52 Ben Taylor wrote:
>> On Fri, Jan 8, 2010 at 4:25 PM, Pavel Heimlich <tropikhajma at gmail.com>
> wrote:
>> > just to let you know the workspace switched to 4.3.90
>> > (announcement http://www.kde.org/announcements/announce-4.4-rc1.php)
>> >
>> > It'll take some time to prune the old patches.
>>
>> can we start making use of the new patch infrastructure, so
>> patches/kdelibs/4.3.85 and patches/kdelibs/4.3.90 exist,
>> just in case we need to go back, without having to wrench
>> ourselves with mercurial?
>
> We can just use "hg tag" to mark the position. I'd really prefer not to have
> tons of patches for all kinds of versions in the repo, but instead say "this
> repo (at revision r) builds exactly *these* versions"; surfing through history
> really isn't all that complicated in Mercurial (except I do miss SVN's "svn cp
> -r" to copy an old revision into the current tree).
All I'm suggesting is that a current version be able to go back exactly on
revision. IE. something's not working quite right, so I set kdelibs manually
to 4.3.85 and rebuild, and it's able to find those patches.
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.
And I'm fine with kde patches getting "obosleted" as we bump tag revisions
in the repo. with the way I do my patches, we can delete the old top level
symlinks to old revisions in patches. If we really want to clean house, we
can remove the old patch %{src_ver} directory.
I can tell you thought, that several times when there's been old patches to
look at, it gave me clues on how to fix an existing or regression problem
that's popped up.
>
>> IE, move current kde patches to %{src_name}/%{src_ver}, then
>> replicate with the new src_ver and then symlink the new rev
>> up to patches. ?Once the "can use relative patch directory"
>> patch goes into pkgtool, we can get rid of the top level patches
>> completely, and keep them with product and revision.
>
> I don't think it makes sense to depend on totally unreleased versions of
> pkgtool;
Laca sounded pretty sure he was going to add the functionality.
> if anything I'd take advantage of the 4.4.0 release to drop support
> for, say, everything before pkgtool 1.3.98. Moving beyond that into privately-
> patched pkgtool land doesn't seem like a good idea unless it brings really
> clear advantages (well, I see one clear advantage of "these are the patches
> for version V of the software" as opposed to having to hg up, check the spec
> file for the version).
Again, if we use the mechanism to have %{src_name}/%{src_ver} for patch
dirs, and then symlink up the patches to spec/patches, then the only maintenance
moving forward is pruning the obsoleted patch symlinks. "IF" Laca incorporates
the patch, then the only thing has has to happen is change the
the patchprefix define from "%{src_name}-%{src_ver}" to
%define patchprefix to %{src_name}/%{src_ver}/%{src_name}-%{src_ver}
and then delete all the symlinks when that base-spec file is updated.
The symlinks are a little ugly, but it still makes working within a
set of patches
much easier, when you don't have to work regular expressions around every
patch that's in the repo.
Ben
