[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] *TELUS Detected Spam*Re: distributed repository: README.txt doc as package requirement
On Mon, Sep 26, 2011 at 2:46 PM, Vincent Manis <vmanis@x> wrote:
> * At the top level, three files with generic information (these
> can be consolidated into one README file, if there's a
> standard skeleton for what a README file looks like).
> - README: general package description
> - INSTALL: [...]
> - COPYING: description of licensing terms
We'll have some way of extracting the README information.
No one ever reads INSTALL and COPYING files, the
installation is automatic, and the license presented to you as a
single term (GPL, BSD, etc.) before you install (optionally with
config settings to whitelist and blacklist specific licenses), so
those files aren't needed.
> On the subject of CPAN, I'm not a Perl user, so don't know much
> about how CPAN packages work. My own experience with CPAN has
> generally been rather frustrating, because most packages I have
> tried to install ended up having unsatisfied dependencies, and
> I'd generally find myself doing several iterations, and end up
> getting three quarters of everything installed before
> discovering one package that was broken or didn't work on my
> OS, or the like (there may be a better way of using CPAN, but
> I'm just relating my experience). I'd prefer dependency
> management to be copied from Debian than from CPAN.
I have packages in CPAN and am a former Debian maintainer,
so I'm familiar with both systems, and there is little technical
difference in them.
Debian packages are of high-quality because 1) they are packaged
by volunteers whose sole responsibility is the package itself, 2)
they have clear policies and guidelines, 3) they have an excellent
internal community and mentoring system, 4) they have more users
than any other packaging system.
CPAN packages can be of lesser quality because 1) they are
packaged at the last minute by programmers whose primary
responsibility is writing the code, 2) library dependencies are
inherently more fragile than the largely self-contained apps that
make up most Linux distributions*, 3) there aren't nearly as
many users, and those users tend to be able to work around
issues by themselves.
* Large collections of related libraries (e.g. Gnome) tend to cause
the most problems for Linux distributions, and the libc5->6 transition
was tough even for Debian.
Scheme-reports mailing list