arch-osx staying in sync archlinux
Kevin Barry
now we basically fork from archlinux and then update them ourselves
our manually download archlinux's latest package and merge it byhand.
This is a bit cumbersome.
I played with git svn but fell back to just using svn and git as
separate programs but working together.
Now if you want to add a new package to arch-osx from archlinux you
can start with "abs2osx --checkout packagename". This will do an svn
checkout of the trunk for archlinux and then run abs2osx on the
PKGBUILD and the .install (if exists).
The next step is to manually verify the PKGBUILD and try to build a
package, if all is successful you can add this to git, INCLUDING the
.svn directory. By including it we will be able to run svn up on it
later to pull changes (Of course we will have merge conflicts often,
but that's expected).
One issue is that svn need the .svn/tmp directory, git won't track
directories so I just added a .svn/tmp/.keep file and tracked that.
I'd rather not track the .svn/tmp/entries as it is a tmp file. The
other option is for the user to add it when they do svn up.
Thoughts? I'll be posting the updated binaries/installer soon (pacman 3.3).
-KB
Fred Alger
>
> I want to try a new approach to keeping our packages updated. Right
> now we basically fork from archlinux and then update them ourselves
> our manually download archlinux's latest package and merge it byhand.
> This is a bit cumbersome.
>
> I played with git svn but fell back to just using svn and git as
> separate programs but working together.
>
> Now if you want to add a new package to arch-osx from archlinux you
> can start with "abs2osx --checkout packagename". This will do an svn
> checkout of the trunk for archlinux and then run abs2osx on the
> PKGBUILD and the .install (if exists).
This sounds pretty awesome. Can't wait to try it out.
> The next step is to manually verify the PKGBUILD and try to build a
> package, if all is successful you can add this to git, INCLUDING the
> .svn directory. By including it we will be able to run svn up on it
> later to pull changes (Of course we will have merge conflicts often,
> but that's expected).
>
> One issue is that svn need the .svn/tmp directory, git won't track
> directories so I just added a .svn/tmp/.keep file and tracked that.
> I'd rather not track the .svn/tmp/entries as it is a tmp file. The
> other option is for the user to add it when they do svn up.
>
> Thoughts? I'll be posting the updated binaries/installer soon
> (pacman 3.3).
This thread looks handy; I use git a lot, but had no idea it was such
a pain to have it track an empty directory:
Hmm... I had a thought about using Git's Subversion integration, but
that's more suited for work as a Subversion client than for what
you're attempting to do here. Using git-svn, each Arch Linux project
would have to be a "submodule" of the main Arch OSX project which
would mean that we'd end up with a separate Git repository for each
Arch project we pull in. Unless we wanted to use git-svn to branch
the whole Arch tree, then clean out the stuff we don't want and merge
in our current Arch OS X stuff... it could work.
I guess I haven't come up with any answers, just stirred the pot.
What do you think?
best,
- Fred.
Loic Nageleisen
On Aug 14, 9:44 pm, Kevin Barry <bar...@gmail.com> wrote:
> I want to try a new approach to keeping our packages updated. Right
> now we basically fork from archlinux and then update them ourselves
> our manually download archlinux's latest package and merge it byhand.
> This is a bit cumbersome.
>
> I played with git svn but fell back to just using svn and git as
> separate programs but working together.
>
> Now if you want to add a new package to arch-osx from archlinux you
> can start with "abs2osx --checkout packagename". This will do an svn
> checkout of the trunk for archlinux and then run abs2osx on the
> PKGBUILD and the .install (if exists).
>
> The next step is to manually verify the PKGBUILD and try to build a
> package, if all is successful you can add this to git, INCLUDING the
> .svn directory. By including it we will be able to run svn up on it
> later to pull changes (Of course we will have merge conflicts often,
> but that's expected).
>
> One issue is that svn need the .svn/tmp directory, git won't track
> directories so I just added a .svn/tmp/.keep file and tracked that.
> I'd rather not track the .svn/tmp/entries as it is a tmp file. The
> other option is for the user to add it when they do svn up.
>
> Thoughts? I'll be posting the updated binaries/installer soon (pacman 3.3).
>
> -KB
good. By including .svn into git we're just asking for trouble e.g
when merging our git repos, or simply just because we have different
local svn versions. And that's from the top of my head.
The correct approach would be to git-svn the arch repo locally. Then
we cherry-pick patches from there and apply them onto our own git
repo.
Alternatively, and without git-svn, get a svn diff between current rev
and head of the package to update,
Anyway we just have to track which revision it matches against,
a .revision file containing just the rev will do.
All of this can easily be wrapped into a script, and you did half of
it with abs2osx --chechout (which is a great idea). Add to --checkout
that it does a svn info and extract the rev, piping it into .revision,
and then clean sup by removing the .svn directory.
Then implement a abs2osx --update that reads the revision, gets the
svn diff, and does a git apply.
Kevin Barry
I did worry keeping the .svn could have unintended consequences. The
version differences is a good point.
> The correct approach would be to git-svn the arch repo locally. Then
> we cherry-pick patches from there and apply them onto our own git
> repo.
I don't know git so well, but I tried for some time and was unable to
get git-svn to act as a remote subtree or submodule. As mentioned
before, inherenting against the whole repo has other issues. Another
option is to have an git-svn version of the archlinux repo, and then
use that as a git remote for our repo, but this requires more work to
keep everything up to date.
> Alternatively, and without git-svn, get a svn diff between current rev
> and head of the package to update,
>
> Anyway we just have to track which revision it matches against,
> a .revision file containing just the rev will do.
> All of this can easily be wrapped into a script, and you did half of
> it with abs2osx --chechout (which is a great idea). Add to --checkout
> that it does a svn info and extract the rev, piping it into .revision,
> and then clean sup by removing the .svn directory.
> Then implement a abs2osx --update that reads the revision, gets the
> svn diff, and does a git apply.
I was thinking about exactly this. My original plan was to do --update
but then found svn up was quicker to setup and figured if there were
issues we could always move to --update. Another advantage of having
abs2osx do it is there might be other things it can do to aid merging,
like possibly revert the prefix changes first, then apply the diff,
then reapply them, for example
version 1
./configure --prefix=/usr --disable-asdf
version 1-osx
./configure --prefix=/opt/arch --disable-asdf
version 2
./configure --prefix=/usr
version 2-osx would have a merge conflict on that line.
But it gets tricky because our manual changes are on top of the
abs2osx changes. But it's something to think about.
-KB
Loic Nageleisen
go. --update could simply "unapply" most (if not all) of its changes
before applying upstream patch, then reapply its own.
Kevin Barry
> Yeah, the more I think of it, the more I see abs2osx to be the way to
> go. --update could simply "unapply" most (if not all) of its changes
> before applying upstream patch, then reapply its own.
arch-osx-tools branch
http://github.com/barryk/arch-osx-tools/tree/master ).
It's beautiful. We can do --checkout, but no .svn is created/used
(it's actually doing an svn export). It stores the repo and the
revision to .archlinux_svnrevision, then we can call --update, which
checksout both the old revision and HEAD (unless you do --update
--revision 123, then it gets 123 instead). Any files that exist in
HEAD but not in ORIGIN or MINE, will be moved over directly. Otherwise
diff3 is run between them creating a merged file back into MINE. It
warns on merge conflicts.
I originally was going to have abs2osx "unapply" before doing the
diff3, however it's actually nicer to preemptively abs2osx on the
ORIGIN and HEAD. This way when there are legit merge conflicts, the
user at least knows that all paths should be /opt/arch, rather than
merged or original paths being /usr, but custom edited paths being
/opt/arch.
Because no .svn directory is needed it shouldn't be so hard to use
--update with our existing packages, just have to guess which SVN the
PKGBUILD was originally based on and created a .archlinux_svnrevision
file for it.
Another thing to think about is if we should be getting these
PKGBUILDs from trunk or repo-i686. I don't know how often archlinux
updates their PKGBUILDs without tagging them, but if they do it often
it might save us a headache.
-KB
Loic Nageleisen
Loic Nageleisen
$ find . -name '.svn' | sed -e "s#/.svn##" -e "s#\./##" | while read
line; do svn info $line | grep Revision | sed "s#Revision:#svn://
archlinux.org/srv/svn-packages/$line/trunk#" >
$line/.archlinux_svnrevision ; done
$ find . -name '.svn' | xargs git rm -r
$ git add **/.archlinux_svnrevision
I love Unix. It never ceases to amaze me how easily some tasks can be
done.
Anyway, the result is pushed to my github repo.
On Aug 16, 11:01 am, Loic Nageleisen <loic.nagelei...@gmail.com>