More about x-packages

[Paulo Cesar Pereira de Andrade]

Donnie Berkholz wrote:
> On 02:19 Wed 19 Dec     , pcpa at mandriva.com.br wrote:
>>   Now, about the system I am working on:
>>   I am using a git mirror of freedesktop, where I use 3 main branches, and
>> modules also have branches with the same name.
>> mandriva         Code that should be ok to add to mainstream
>> mandriva+custom  Work in progress patches, or things that are not
>>                  considered mainstream quality, but fix some issue
>>                  in the distro
>> mandriva+gpl     The distinction is due to the fact that GPL code currently
>>                  isn't accepted in main Xorg, and branch created to allow
>>                  easier integration of such patches/mods, and still keep
>>                  the repository in a format that allows easy pulling
>>                  for other people that want to make sure only a permissive
>>                  license is used.
>>   Currently, I am experimenting with git-archive to generate a tarball,
>> and git-format-patch to generate the patches. The benefit is that it can
>> be automatized, and there is no need to store huge binary files, and only
>> files under version control enter the tarball. The bad side is that it is
>> something new, and you can find people that dislike it. I generate
>> tarball/patches to submit to a ``standard rpm build system''.
>
> In Gentoo, we use the upstream tarballs, verified by MD5/SHA1/etc, and 
> add a set of patches, independently maintained in CVS. An improvement to 
> our setup might store the patches with stgit or similar to ensure 
> they're automatically ported across releases.

  I expect to have everything easy to adapt all the time, and if I get 
conflicts,
should be minimal, so I could fix it in my computer before pushing to 
another
"pseudo master" repository here.
  For example, in the mandriva+gpl branch, I have integrated the vnc 
patches,
and a few other patches/scripts from Debian that are licensed under GPL, and
soon, should have more GPL licensed code. While most of them are trivial,
the vnc patch, currently is over 24K lines of patches, so keeping this 
integrated
may avoid future headaches by needing to either drop it, or fix all the 
conflicts.
  Also of course, an easy way to "cherry-pick" patches from master to 
the stable
branch, or any other cool git feature :-)

> I'm not (yet) convinced that maintaining our own repos and generating 
> our own tarballs would lower the maintenance burden, since the number of 
> patches we have against modular X is dramatically lower than the number 
> we had with the old monolithic X (~10 vs 100+). Furthermore, almost all 
> our patches make it upstream each release so there is no porting between 
> releases.
>
  Well, I don't have it fully implemented yet, neither "several month" of
experience with this approach to tell about my experiences :-). This method
requires some "baby sitting" by knowing what is going on, and updating the
local git mirror, potentially fixing conflicts. But, unless a "0% 
maintenaince"
approach of only donwloading/building upstram tarballs is used, I believe
having git to store local modifications or confliciting ones like the GPL
licensed code, will require a lot less work to maintain, and allow having
almost everything automatized.
> Thanks,
> Donnie
Paulo