This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: RFC: unofficial packages
- From: "David A. Cobb" <superbiskit at cox dot net>
- To: Charles Wilson <cwilson at ece dot gatech dot edu>, cygwin-apps <cygwin-apps at cygwin dot com>
- Date: Fri, 12 Jul 2002 15:31:14 -0400
- Subject: Re: RFC: unofficial packages
- Organization: CoxNet User
- References: <3D2CC35C.3080406@ece.gatech.edu>
Chuck, this all sounds pretty complicated. One thing for sure: before
anything like this would be tolerable we need SETUP.EXE enabled to
*remove* a mirror. Right now I don't think that's possible. If I have
a bad experience from a "contributor" I don't need to look at her stuff
again! Once bitten, etc.
BTW, do you need to fix your "Reply-to:" on these things? My mailer
wanted to send this just to you.
Charles Wilson wrote:
Some time ago, I brought up the following issue:
I have a number cygwin ports of various useful tools (see bottom),
that are packaged in a setup-compatible way. (Yes, I even use method
2 for local compiles...call me a masochist). I would be perfectly
willing to make them available to a wider community -- but I do NOT
want to maintain them. They work for me; the only bug reports I care
about are my own.
So, they are not going to be ITP'ed any time soon. OTOH, I would also
be willing (eager) for someone else to grab my finished port and just
"take over" -- they could ITP it and the whole deal.
So, I previously had mentioned the possibility of a separate
"unmaintained" tree, on the cygwin mirrors, distinct from "release".
Bad idea -- even if we do get semi-automated uploads to sourceware.
If the packages are distributed via the cygwin mirrors, then we WILL
get questions about them on the main lists. This is bad.
So, here's an alternate proposal, given setup's existing capability
for federated, non-mirror download sites:
-------------------------------
Packages (or "private" versions of official packages) from User URLS
(e.g. sites that are not official cygwin mirrors) should be presented
in a different color, or bold, or with a shaded background, or
something. Somehow, they need to be visually distinct (textually for
the visual impaired?) from "official" packages -- in fact, if I put a
version of gcc on my site, then someone clicking thru the available
versions should see the official version (without special
highlighting), my version (with special highlighting), etc.
Heck, we may even want the actual URL to be displayed *right there* in
the chooser, for non-mirror sites:
I use BOB's site for new game ports
I use BILL's site for extra perl module packages
But I definitely DON'T want bob's perl module packages, so it's not
enough to know "perl_cpan_module-X.XX-X" is from a non-mirror URL -- I
need to know that it's from BILL and not BOB.
Anyway, suppose there's a web page at cygwin.com which lists various
"unofficial cygwin package" locations -- like my /cygutils/testing
site, and the lilypond site, etc.
Packages from user URLs need to be distinguished from packages from
official mirrors -- that's the only way a user can tell if the updated
version of gcc is an official update, or just someone's private
version -- or if some unofficial person was trying to pollute the
federation. [e.g. BOB makes a name for himself as a useful site for
cygwin ports of games, and then slip in a trojan "update" of bash]
Anyway, in this scheme, 'unofficial' packages can be federated, and
not centrally controlled. It's understood that 'unofficial' packages
will NOT be supported by the main cygwin list -- and each person who
puts up a 'unofficial' site can set their own support policy.
And end users should beware of updating 'core' cygwin packages from
non-mirror sites (as indicated by the color/bold/shading). If color
were sufficient (it isn't; think colorblind, visually impaired, laptop
displays), then I'd suggest: yellow(caution) for packages from
non-mirror sites, that do not have corresponding official packages;
red(danger) for packages from non-mirror sites that will "upgrade"
official packages. PLUS unofficial URLS printed *right there* in the
chooser.
My support policy -- for "unofficial packages" from my website --
would be "These packages work for me. If they don't work for you, I
don't care. If they trash your system, destroy your carpet, or kill
your dog, it's your problem, not mine. All mail goes to /dev/null.
Use at your own risk. If you want to see these packages as part of
the official cygwin distribution, download the -src archive(s), and
see http://www.cygwin.com/setup.html. I make no claim of ownership or
control on the cygwin ports of the packages provided here."
The only danger (other than the trojan possibility mentioned above)
would be if two "unofficial" sites got into a pissing match: each site
provides its version of 'pkgfoo", and they get into a
release/version-number 'bidding war'. This is only a problem if both
unofficial sites are popular with the same people. Also, it's a
self-correcting problem: eventually, one site or the other or both
will become UNpopular with users and they'll drop it from their
setup.exe list -- hence no more conflict.
------------------------------
So, this proposal is actually two parts:
1) policy: how to handle unofficial (e.g. non-ITP'ed) but setup
compatible ports. My proposal: don't. They don't need to be
distributed via the cygwin mirror system; that's what federation is
all about. But, to make things easier for end users, and to give some
slight warning against possible trojans...
2) implementation:
(a) visually distinguish packages (or versions of official
packages) from User URLS -- and display the site URL in the chooser.
What's the best way to do this?
(b) an extension of the existing "related sites" web page, to
include a section with "Here are some setup-compatible sites that
offer cygwin packages. type these URLs in to setup.exe, and press Add
URL."
I realize that (2)(a) is sort of a taboo "wouldn't it be nice if
setup.exe..." comment; and I'm willing to give it a go with the
sources, if no one else can. However, it's more important to know if
the community thinks this is a good idea or not, before wasting the
time implementing it...
Comments?
--Chuck
epstool
help2man
jpeg2ps
libungif
netpbm
plotutils
pstoedit
pstoepsi
pstotext
tgif
ungifsicle
--
David A. Cobb, Software Engineer, Public Access Advocate
"By God's Grace I am a Christian man, by my actions a great sinner." -- The Way of a Pilgrim; R. M. French, tr.
Life is too short to tolerate crappy software.
.