[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-hackers] call for repository/chicken-setup organization pla
Re: [Chicken-hackers] call for repository/chicken-setup organization plans
Tue, 26 Feb 2008 09:17:08 -0600
Thunderbird 188.8.131.52 (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.
*And by every I mean most. I understand that some modules aren't, but it's
considered a best practice.
felix winkelmann wrote:
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
of this implementation and community development style (-> chaos ;-).
Chicken-hackers mailing list