Mail Archives: cygwin/2002/05/02/17:57:36
Charles schrieb:
[...]
> Determine which patches should be sent on to Bruno Haible for inclusion
> in the upstream version. Advocate their adoption on that list. Monitor
> that list for information that may affect the cygwin port.
That is easy...(monitoring), the other point, we both tried to contact
Haible, he ignores it. Maybe the next release will introduce some
changes, but I don't believe it.
> But most importantly, the maintainer of libiconv should *know something
> about internationalization*. I'm a dumb American.
[...]
I am a stupid Kraut.
I'm not qualified too...
> Then, of course, there's the simple fact that I am trying to get other
> people to adopt my existing packages; not take on new ones. It's only
> my sense of "parenthood" that's kept me around as long as I have.
:-)
> My next computer will be a Mac. I'm now doing most of my development on
> Solaris or Linux. And, since I use TeX for document creation, I don't
> even need MSOffice anymore. MS freedom is approaching. *I will leave
> cygwin* at some point; how many orphaned packages do you want me to
> leave behind?
There will be someone to take it over then.
(& MAC users are weenies...)
>> And also libungif is ready. You are already the grafic libs
>> specialist;) Why not put one more up to the mirrors?
> See above. No more packages. Period.
Ok. I understand.
[....]
> No, I will not be pressured on this.
I didn't want to bug you.
> There is already a volunteer for libungif, and for Berkeley DB (I'm not
> sure the volunteer wants to go public yet). Several people have
> wondered aloud about libiconv (Paul Miller, Soren Andersen, others) --
> but as yet no-one cares enough to just take the already-ported package
> and adopt it.
Oh yeah, I hope Berkeley DB will get out soon.
I really need it for Perl.
> Now, I think it might be a good idea if there were a parallel tree to
> 'release' -- call it 'unsupported' -- where the packages follow the same
> setup.exe-compatible standards as regular packages, except:
> --prefix=/usr/local
> --sysconfdir=/usr/local/etc
> documents go into
> /usr/local/doc/<PKG>-<VER>/ and
> /usr/local/doc/Cygwin/
> Official 'release' packages MUST NOT EVER depend on 'unsupported' packages.
> The 'unsupported' repository would serve as a place where people (like
> me) who port a package, can make it "officially" available to users via
> the cygwin mirror system -- BUT with the attitude of:
> "it works for me. if it works for you, great. otherwise, don't bug me"
> 'unsupported' packages could be adopted for migration to the "release"
> tree by any sufficiently motivated volunteer maintainer. Or, if the
> original submitter flakes out, anybody else could also submit an updated
> replacement package...but leave their contribution in the 'unsupported'
> tree too.
> If there were a tree like that, then I would submit my "other" packages
> there.
Well, actually there is, they all fetch libiconv from your site and use it,
just because some packages ask for it. It worked for me since you loaded up
the first binary to ftp.uni-erlangen.de and before the shared version I
used a static, selfcompiled one.
I like the idea of having unsupported packages. I have also some
binaries at my webserver, 'joe' gets fetched really often and I get
about one question about joe per month. I wanted it to be included
in the dist, but it wasn't heard/uploaded...
So I keep it at my site. Just like some other packages.
E.G. I have a Berkeley-DB binary of 4.0.14: http://62.138.63.18/cywgin/db/
And Expat 1.95.2 (shared): http://62.138.63.18/cywgin/expat/
Gerrit
--
=^..^=
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -