This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: unofficial packages

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




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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]