This is the mail archive of the cygwin-xfree mailing list for the Cygwin XFree86 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: 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/


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