[arch-general] abs [WAS: arch-dev-public] Package maintainers wanted - heimdal, db, abs

Ray Rashif schiv at archlinux.org
Sat Nov 13 07:35:41 CET 2010


On 13 November 2010 06:13, C Anthony Risinger <anthony at extof.me> wrote:
> On Fri, Nov 12, 2010 at 3:56 PM, csgeek <csgeek at archlinux.us> wrote:
>> Somewhat related question....
>>
>> I've seen a few places deploy git based build systems.
>>
>> funtoo (re-implementation of gentoo's portage but git based) and the arch
>> based that was linked above.
>>
>> I'm just curious.. at some point wouldn't that just create excessive history
>> that's not needed?  Do you really care about PKGBUILD of something that's
>> 2..3.... 5 years out of date?
>
> what's excessive?  your talking about 95%+ highly compressible text
> files, with highly differentiable change sets and relatively slow
> updates (vs. an active source code tree); i don't see any problems.
> it won't accrue much at all imo, even after several years (decades?),
> but i don't have numbers to back that up.
>
> however it is possible to use grafting and other techniques to
> prune/drop history, and still work with the repo.  git and the data
> model will evolve too; last time i checked there was
> specifications/steps toward integrating v4/v5 packfile format.
>
> git does however, need a good library to bind to; the code right now
> is... ehm... yeah...
>
>> Then again.. if we could use something like that.. to checkout an old
>> version of a package, that would be well worth it.  One thing that was
>> available in gentoo that I miss in arch is the ability to have 2-3 version
>> of a package available.
>
> yeah, you could get any PKGBUILD you needed, with ease, and diff then
> against anything else...
>
> maybe even, dare i say, p2p share the immutable objects around...

Binary packages are not version-controlled. You can retrieve older
versions of PKGBUILDs from our Subversion repository. You can diff
between revisions as well. For something so straightforward, GIT is no
more helpful. PKGBUILDs don't get multiple commits by multiple
contributors to the extent software projects do, where GIT would make
sense.


More information about the arch-general mailing list