This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
RFC: unofficial packages
- From: Charles Wilson <cwilson at ece dot gatech dot edu>
- To: cygwin-apps at cygwin dot com
- Date: Wed, 10 Jul 2002 19:29:32 -0400
- Subject: RFC: unofficial packages
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