chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] call for repository/chicken-setup organization pla


From: Ozzi
Subject: Re: [Chicken-hackers] call for repository/chicken-setup organization plans
Date: Tue, 26 Feb 2008 09:17:08 -0600
User-agent: Thunderbird 2.0.0.9 (Macintosh/20071031)

I don't know much about CPAN, as I've never learned Perl, but I know a lot of people think it's really great.

Since, from what I gather, the eggs repository is roughly based on CPAN anyway, why don't we copy CPAN further?

CPAN doesn't use a revision control system. Every* module is commited as an archive with a version number, like my-module-1.2.tgz. Modules can't be changed once they've been updated -- a new version has to be uploaded.

So, my half-baked proposal is to just have a directory that we upload .egg files to, separate from the SVN repository for Chicken development, and whatever version control system the egg author chooses to use. Version info could be scanned out of the egg, invalid eggs could be rejected somehow, etc.

I'd be happy to write up something a bit more in depth if there isn't some obvious reason that this won't work which I've overlooked.


Ozzi

*And by every I mean most. I understand that some modules aren't, but it's considered a best practice.


felix winkelmann wrote:
Hi!

I'm looking for proposals about how to find the ultimate repository/packaging
combination, or better: what could we do to keep a central, revision controlled
repository of chicken extensions, manage chicken+extension interdependencies,
keep users of historical chickens safe from featurecreep, etc. This influences
usage, development, installation, backups, maintenance and many other things,
so is really critical and should be well thought out.

It would be cool if, instead of "hey, this would be nice:..." or, "but
is must support
signing of packages!", we could gather somewhat more elaborate proposals
that try to specify details instead of just handwaving particular issues away.

I don't think any existing packaging system addresses our needs - we should find
something chicken-specific, to have maximal freedom to adapt it to the
particulars
of this implementation and community development style (-> chaos ;-).

Please help!


cheers,
felix


_______________________________________________
Chicken-hackers mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/chicken-hackers




reply via email to

[Prev in Thread] Current Thread [Next in Thread]