RFC: unofficial packages

[David A. Cobb]

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.
.