RFC: unofficial packages

[Charles Wilson]

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