Re: More git policy: xsfbs and bundled apps packages
On Wed, Jan 10, 2007 at 04:31:07PM +1100, Drew Parsons wrote:
>
> > The apps are fairly easy. We use the upstream* branches and just extend
> > it so we have individual upstream* branches for each upstream app repo.
> > These all get merged in to debian as the need arises.
>
> Is it as simple as that? The upstream apps are all separate repos, but
> for our convenience we've collected them into single packages, for
> instance xbase-clients (also xprint-utils and xutils). So we'd want
> xbase-clients managed as only one repo, at least as far as the debian*
> branches go, which conflicts with all the individual upstream* branches
> for each app contained in xbase-clients. We wouldn't be able to use
> git-pull in the usual way (unless git is more flexible than I realise.
We should be able to. You can test it yourself. Make a temporary repo with
a file "a" in it. Once this is checked in, make a second branch with a file
"b". Then go back to the master branch and make a third branch with a file
"c". Your layout will be like this then:
branch files
----- -----
master a
second a b
third a c
Then you can go back to master and pull second and third in independantly.
You'll end up with master having files a, b, and c. This is pretty much the
model for these packages. Since the second and third branches are unaware
of each others individual files, they don't get deleted when their changes
are pulled in to the master branch.
> Does it have a concept of "subrepos" where a subdirectory pulls from a
> different repo? I presume not otherwise this would have solved the
> xsfbs problem.) Cherry picking updates one-by-one would still work,
> one way or another, and I imagine we're not likely to make a whole lot
> of changes to the apps, so it wouldn't be a huge problem. Would be sure
> to break git-buildpackage I should expect.
Git doesn't have the concept of subrepos unfortunately. It'd be nice, but
this method should make it work. And we wouldn't have to change our
packaging or anything.
> > xsfbs doesn't have a good solution really. We can keep a single
> > repository for xsfbs and then manually merge it when we do updates. We can
> > probably script that locally to make it easier when changes to xsfbs do
> > happen, although I'd still like to wean us off it this next release cycle.
> > We could also create a hook script to automagically pull it in, but that's
> > a lot of overhead, and I think a local script is probably a better idea.
>
> Maintaining a local script shouldn't be a problem, I think. Might be
> an idea to have everyone with project write access get notified by
> email when it needs updating (in case we miss an announcement on
> debian-x). What ideas do we have for eliminating xsfbs?
I've not looked at it for a while, but the first thing would be to move our
quilt stuff to what's included in the quilt package itself. We could
probably just delete large chunks of xsfbs at this point, since a lot of it
we aren't using any more, like the fonts stuff (now handled by debhelper).
The shell scripts are more problematic, since I don't think there's a good
general replacement in Debian for these. We may have to create one.
- David Nusinow
Reply to: