RFC: unofficial packages
David A. Cobb
superbiskit@cox.net
Fri Jul 12 12:31:00 GMT 2002
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.
.
More information about the Cygwin-apps
mailing list