New Maintainer

[DRC]

After looking into this further, it doesn't look as if porting the current
X.org code to Cygwin is going to be straightforward, particularly since our
group has no prior expertise with Cygwin porting or packaging.  Thus, I
don't think that maintaining Cygwin/X is something that we are going to be
able to tackle.  The general consensus is that we have much less expertise
with Cygwin and X.org than you guys do and certainly less than the
cygwinports people.  Yet neither community has been able to port xorg-server
to Cygwin, so what hope do we have?  In any sense, our main justification
for porting the most recent X.org code to Cygwin was to provide a vehicle
for introducing some new patches to enable certain features that are needed
by our project (VirtualGL.)  But on further reconsideration, that seems to
be tantamount to building our own highway to improve our car's gas mileage.

I wish you all the best.

Darrell

> -----Original Message-----
> From: cygwin-xfree-owner@cygwin.com 
> [mailto:cygwin-xfree-owner@cygwin.com] On Behalf Of Charles Wilson
> Sent: Friday, March 28, 2008 12:09 PM
> To: cygwin-xfree@cygwin.com
> Subject: Re: New Maintainer
> 
> Christopher Faylor wrote:
> > On Thu, Mar 27, 2008 at 08:58:17PM -0500, Charles Wilson wrote:
> >> DRC wrote:
> >>> Is there a spec for which files go in which packages, 
> etc.?  Any other
> >>> advice to get started, or should I just start downloading 
> and tinkering?
> >> Given the "new" modular structure of the X.org releases, 
> it seems to me 
> >> that each "module" should be treated independently.  
> However, that being 
> >> said, each "module" may represent multiple tarballs.  E.g.
> > 
> > I don't think it makes sense to invent a new scheme for 
> what goes where.
> > 
> > Just pick a distro (Fedora, Gentoo, SuSE, Ubuntu, etc.) and 
> mimic that.
> 
> Chris, this is NOT a new scheme, and the linux distros' 
> methods cannot 
> be directly mapped to cygwin with regards to shared 
> libraries, because 
> .so's != dlls, and ld.so != Windows Runtime Loader.  There 
> will always 
> be some differences between our packaging and the *nixes.
> 
> But in this particular case, what is "new" about the breakdown iisted 
> below? Doesn't it map almost exactly to how Fedora 
> distributes libXext 
> in rpms?
> 
> libXext-1.0.3-1-src.tar.bz2
> libXext-1.0.3-1.tar.bz2
> 
> libXext-devel-1.0.3-1.tar.bz2
> libXext6-1.0.3-1.tar.bz2
> 
> (These filenames were taken directly from Yaakov's libXext cygport.)
> 
> The only real difference is that the *nixes would provide 
> only the DLL 
> (so) package 'libxext6' and the -devel package 
> 'libxext-devel'; there's 
> nothing specific in this case that really needs to go in a "base" 
> package 'libxext'.  However, in Cygwin's case I've noticed that 
> setup.exe (at least in the past) got annoyed if you have:
>    foo-*-src.tar.bz2
>    libfoo6-*.tar.bz2      (external-source: foo)
>    libfoo-devel-*.tar.bz2 (external-source: foo)
> but do not have
>    foo-*.tar.bz2
> Maybe this is a bug in setup and we should fix it, or maybe 
> it is not a 
> problem anymore.  In any case, we need to put the cygwin 
> README, and the 
> "normal" README/THANKS/AUTHORS/ChangeLog goobledygook 
> somewhere. Might 
> as well be in the (otherwise empty) foo-*.tar.bz2 package.
> 
> As it happens, Yaakov chose to put the man3 docs in the "main" foo-* 
> package, instead of the libfoo-devel-* package. I'd probably 
> do it more 
> like the *nixes, in this case. But really, is THIS significant?
> 
> 
> We can and should, of course, use the Linux distro's 
> packaging choices 
> as informed guidance, and I'm sure that's exactly what Yaakov 
> did when 
> he created his cygports. (The *nixes whose X components are 
> based on the 
> modular X.org source DO treat each module as independent 
> subsets [that 
> is, separate *.src.rpm's, separate lib*N rpms, separate 
> lib*-devel rpms 
> etc]...although they naturally tend to update/release them in 
> simultaineous waves).
> 
> 
> Frankly, I'd want to make things as easy as possible for the new X 
> maintainer -- and since an experienced, knowledgeable person 
> has already 
> done a HUGE portion of the necessary work, I'd /start/ with Yaakov's 
> cygports...and *maybe* make some slight modifications if 
> SuSe/Fedora/Debian did something the new X maintainer particularly 
> likes.  (Not the other way around, as you seem to suggest).
> 
> 
> My email was an attempt to explain the general way that 
> "dll-providing" 
> cygwin packagesets are and should be subdivided, with a short 
> description of the 'why' behind it all.  It's the way I've been 
> providing DLL packagesets since 2002 or before. I'm surprised you 
> consider it "new".
> 
> --
> Chuck
> 
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Problem reports:       http://cygwin.com/problems.html
> Documentation:         http://x.cygwin.com/docs/
> FAQ:                   http://x.cygwin.com/docs/faq/
> 


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/