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

[C Anthony Risinger]

On Sat, Nov 13, 2010 at 12:35 AM, Ray Rashif <schiv at archlinux.org> wrote:
> 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.

i wasn't implying they were; the question/answers seem to be about
PKGBUILDs and related.

that said it doesn't mean they couldn't be.  we history pruning and
various other techniques, such a system could be constructed where
users are not required to have every package ever built, only what
they wanted, but other peers could maintain the history as far back as
they wanted.  when all peers drop a point in history, it is lost (but
at that point it would seem no one cares)

the binary packs themselves could also be unversioned, and only their
(very strong) fingerprint maintained in the history.

>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.

that was an obvious example.  git's data model is very simple and
flexible, svn is a convoluted piece of <insert>.  with git i can
target specific branches for any repository; i can munge history with
ease and finesse; i can share object repositories with unrelated
projects; i can use the hooking system to create automatic
development/staging/production platforms for my team.  i could go on
for much longer, but this is a well trodden path.  git gives you the
flexibility to create that which has not yet been discovered.

>PKGBUILDs don't get multiple commits by multiple
> contributors to the extent software projects do, where GIT would make
> sense.

they will in time my friend, if i get my way :-) this is a goal i am
actively pursuing.  git makes sense in all capacities; you don't need
to be a kernel or display server to realize the extent it can simplify
your development life.  i use it every day.  it rocks.

C Anthony