Re: Upcoming X.org release and splitting packages
On Fri, 19 Mar 2004, [ISO-8859-1] Frédéric L. W. Meunier wrote: On Fri, 19 Mar 2004, Harold L Hunt II wrote: Frédéric L. W. Meunier wrote: --with-terminal-type=xterm-xfree86 was just so I wouldn't get it set to xterm by default (lynx etc are black and white with it). I'm not sure this would be a good idea to change the default if we were not doing this before anyway. Then again, I would rather defer judgement on this one to someone with more knowledge on this subject. Question to Thomas: Why make xterm the default if all (?) ncurses applications run in black and white with it ? Sure, you can change .Xdefaults etc, but go figure. That's one of those situations where any of the solutions are not good for everyone. If you're using xterm for one machine - sure, that's good. But if you ssh/rsh/telnet/etc to another machine where that $TERM value doesn't correspond to anything in the remote machine's termcap/terminfo, then it doesn't work well. Two problems may occur there: the ssh/rsh/telnet/etc client may check $TERM and refuse to complete the connection (this applies to some telnet daemons apparently). Even when the connection is completed, many users don't cope well with the fact that their $TERM isn't useful. The other solution as you note - setting $TERM to xterm works, but color usually isn't available. Setting it to one that does color has the disadvantage that there's always a terminal emulator (or two, etc) that doesn't match the terminfo. I compile-in the correct $TERM value for each client for which I have source (and have little use for the ones that hardcode it, anyway except for testing). On remote machines I've updated the terminfo entries so they work. But that's too much work for the typical user. The solution you choose really depends on the type of questions you want to answer about what's broken... --disable-tek4014 --disable-vt52 seems to be recommend because it adds bloat and only a few people use it. Might not be a bad idea, but the .exe is only 233 KiB at the moment. It isn't exactly bloated. :) According to INSTALL: This reduces the executable size by 17% (checked 1999/3/13). Thomas should update it. I didn't notice 1/4 of it in the size. That probably depends on the platform. Some executable formats are not really byte-granular, for instance. But I'll check on one of my Linux boxes to see if a dependency has crept in. 17% would be about 20kb. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net
Re: Upcoming X.org release and splitting packages
Harold == Harold L Hunt, Harold writes: Harold 1) Due to popular demand, rename the prog package to devel. The Harold name devel matches the defacto standard used by other packages for Harold link libraries and header files; most people have no idea what the Harold prog package is for, but they do know what a devel package is for. yap Harold 2) Split the bin package into at least a few pieces (but not too Harold many pieces): Harold 2a) bin-dlls will contain the .dll files only. This would allow Harold packages like emacs or xemacs to depend only on bin-dlls instead of on Harold the entire bin package which includes programs not used by emacs nor Harold xemacs. great Harold 2b) bin-lndir would contain the lndir utility. lndir has no Harold dependence on X libs and can be used by any programmer for non-X Harold projects. +1 especially useful for some packages configuring only in their source tree Harold 2c) bin-apps would contain all other applications originally Harold contained in bin but not contained in bin-dlls nor bin-lndir. sure Harold 3) Rename all fonts packages from f100, cyr, fenc, fnts, fscl to Harold something like fonts-100dpi, fonts-cyrillic, fonts-encodings, Harold fonts-75dpi, and fonts-scalable. finally Harold 4) Split the fnts package into a fonts-required and Harold fonts-75dpi. fonts-required should be a very small package that Harold would allow people to minimize their download if they are using Xdmcp Harold to reach a KDE or Gnome desktop, both of which you client-rendered Harold fonts (few fonts required on your Cygwin/X host in that case). what ever you want, ... Harold 6) Rename fsrv to font-server. yap Harold 7) Rename html to manual-pages-html. Harold 8) Rename man to manual-pages. maybe something with doc* is more in line with other packages Harold Harold go ahead Ciao Volker
Re: Upcoming X.org release and splitting packages
Frédéric L. W. Meunier wrote: On Wed, 17 Mar 2004, Harold L Hunt II wrote: We will soon (possibly next week) be releasing a new version of all Cygwin/X packages built from the source code tree managed by X.org and hosted on freedesktop.org. This will be a very good thing since all of the Cygwin/X developers will be able to stay in sync with the exact code that is in distribution via CVS, compared to our current system today where the code in distribution has many differences from that in CVS. The rebuild won't mean much to end users: all libraries remain binary compatible with the current packages and the contents of the release (programs, etc.) will be almost identical. What are the main differences between it and XFree86 4.4.0 ? Are things like XTerm 185 included, or everything that goes to XFree86 can't to X.org ? I don't know about XTerm 185 specifically, but this release should contain all fixes and features that were added to the XFree86 project's source code tree for the 4.4.0 release. 2) Split the bin package into at least a few pieces (but not too many pieces): 2a) bin-dlls will contain the .dll files only. This would allow packages like emacs or xemacs to depend only on bin-dlls instead of on the entire bin package which includes programs not used by emacs nor xemacs. Maybe do the same for Lesstif ? Heh, one thing at a time. :) 2b) bin-lndir would contain the lndir utility. lndir has no dependence on X libs and can be used by any programmer for non-X projects. Nice. lndir is very useful when a /path/to/configure options doesn't work as expected due to lack of Automake support or brokeness. Yup, I use it all the time for that. 2c) bin-apps would contain all other applications originally contained in bin but not contained in bin-dlls nor bin-lndir. I thought you'd split it more, like only adding what's really essential, and move xbiff, xclock, xedit, xman, etc to a separate package. But how to know what's essential ? And I guess imake, makedepend, /usr/X11R6/lib/X11/config, etc could go in devel ? Well, I am debating whether or not to start going down this slippery slope... two or three category types of packages may be okay I suppose. Harold
Re: Upcoming X.org release and splitting packages
David Fraser wrote: Harold L Hunt II wrote: We will soon (possibly next week) be releasing a new version of all Cygwin/X packages built from the source code tree managed by X.org and hosted on freedesktop.org. This will be a very good thing since all of the Cygwin/X developers will be able to stay in sync with the exact code that is in distribution via CVS, compared to our current system today where the code in distribution has many differences from that in CVS. The rebuild won't mean much to end users: all libraries remain binary compatible with the current packages and the contents of the release (programs, etc.) will be almost identical. In case you have not noticed, I created a build and packaging script system for Cygwin/X last week (took 60+ hours). This script system does a few things for us, such as allowing us to easily distribute source tarballs via Cygwin's setup.exe. More importantly, the script system allows us to exercise a finer control over what files each package contains and how many packages we break the distribution up into. We can very easily rename current packages when we make the next release, we can split existing packages into pieces, or we could take a set of packages, roll them back together, then split that entire mess into mixed pieces of the originals. I am mentioning this now because I can think of a few things that I would like to change in our package layout in time for the X.org release, but I would also like to get feedback from the community on what you think would be useful. Please take a look at my brief list of ideas below and send your thoughts to the mailing list if you have something about our packaging that you have wanted changed for a long time. My Proposals for Packaging Changes == 1) Due to popular demand, rename the prog package to devel. The name devel matches the defacto standard used by other packages for link libraries and header files; most people have no idea what the prog package is for, but they do know what a devel package is for. +1 2) Split the bin package into at least a few pieces (but not too many pieces): 2a) bin-dlls will contain the .dll files only. This would allow packages like emacs or xemacs to depend only on bin-dlls instead of on the entire bin package which includes programs not used by emacs nor xemacs. 2b) bin-lndir would contain the lndir utility. lndir has no dependence on X libs and can be used by any programmer for non-X projects. 2c) bin-apps would contain all other applications originally contained in bin but not contained in bin-dlls nor bin-lndir. This sounds great... although I wonder whether it would be good to split bin-apps into bin-apps (xterm, xeyes, etc) and bin-utils (xauth, xhost etc) Not sure... it might work okay. 3) Rename all fonts packages from f100, cyr, fenc, fnts, fscl to something like fonts-100dpi, fonts-cyrillic, fonts-encodings, fonts-75dpi, and fonts-scalable. +1 4) Split the fnts package into a fonts-required and fonts-75dpi. fonts-required should be a very small package that would allow people to minimize their download if they are using Xdmcp to reach a KDE or Gnome desktop, both of which you client-rendered fonts (few fonts required on your Cygwin/X host in that case). +1 5) Rename the lib package to something more meaningful. The name currently implies that it might contain link libraries or run-time libraries, but it really contains files shared among X packages. Perhaps shared-files would be a better name. I would appreciate it if someone would look into what Debian and/or Fedora call this package. Fedora has all the /usr/X11R6/lib/locale/ files, /usr/X11R6/lib/X11/rgb.txt /usr/X11R6/lib/X11/XErrorDB and /usr/X11R6/lib/X11/XKeysymDB in XFree86-libs-data, the /usr/X11R6/include/X11/bitmaps/ files in XFree86-devel, and on my system doesn't have /usr/X11R6/lib/X11/xedit/lisp/ files so I can't say. So I guess libs-data is a good name... Okay, thanks for looking into that. libs-data doesn't sound too bad. Now to figure out what debian calls it. 6) Rename fsrv to font-server. +1 7) Rename html to manual-pages-html. 8) Rename man to manual-pages. what about docs and docs-html for these too? There was a different docs package that had the protocol specifications documents in it. I figured that manual-pages would imply that these are documents read with man, not regular text documents. The html package is just html versions of those manual pages. I dunno... let me know what Fedora calls these packages. Let us know what you think of those and send in your own suggestions as well. Harold Just some ideas Thanks, Harold
Re: Upcoming X.org release and splitting packages
On Thu, 18 Mar 2004, Harold L Hunt II wrote: Frédéric L. W. Meunier wrote: What are the main differences between it and XFree86 4.4.0 ? Are things like XTerm 185 included, or everything that goes to XFree86 can't to X.org ? I don't know about XTerm 185 specifically, but this release should contain all fixes and features that were added to the XFree86 project's source code tree for the 4.4.0 release. Most of them. X.Org's changelog doesn't give enough detail to tell without running diff. However diff'ing the trees shows lots of keyword mismatches (X.Org's copy is consistently incorrect), so there's a lot of diff to read. xterm patch #185 is post-4.4, and according to fd.o's CVS is not in the release-1 branch. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net
Re: Upcoming X.org release and splitting packages
Harold L Hunt II wrote: 5) Rename the lib package to something more meaningful. The name currently implies that it might contain link libraries or run-time libraries, but it really contains files shared among X packages. Perhaps shared-files would be a better name. I would appreciate it if someone would look into what Debian and/or Fedora call this package. Common or shared are standard for Windows software. For example, C:\Program Files\Common Files\Microsoft Shared, C:\Program Files\Common Files\Symantec Shared... -JT
Re: Upcoming X.org release and splitting packages
On Thu, 18 Mar 2004, [ISO-8859-1] Frédéric L. W. Meunier wrote: On Thu, 18 Mar 2004, Thomas Dickey wrote: xterm patch #185 is post-4.4, and according to fd.o's CVS is not in the release-1 branch. It may be worth to make it a separate package and start using your sources from http://invisible-island.net/xterm/ when they're newer (most of the time). Not exactly - though I maintain my own rcs archives of xterm, the patch numbers do correspond to commits in XFree86. So there's no difference from that standpoint (of being newer). Occasionally there's a minor bug fix I add to XFree86 but don't make a new xterm patch, but the reverse is not true. However, I do make xterm patches more frequently than XFree86 releases occur - that's simply a matter of 60,000 lines of code compared to 3 million... -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net
Re: Upcoming X.org release and splitting packages
Thomas Dickey wrote: On Thu, 18 Mar 2004, [ISO-8859-1] Frédéric L. W. Meunier wrote: On Thu, 18 Mar 2004, Thomas Dickey wrote: xterm patch #185 is post-4.4, and according to fd.o's CVS is not in the release-1 branch. It may be worth to make it a separate package and start using your sources from http://invisible-island.net/xterm/ when they're newer (most of the time). Not exactly - though I maintain my own rcs archives of xterm, the patch numbers do correspond to commits in XFree86. So there's no difference from that standpoint (of being newer). Occasionally there's a minor bug fix I add to XFree86 but don't make a new xterm patch, but the reverse is not true. However, I do make xterm patches more frequently than XFree86 releases occur - that's simply a matter of 60,000 lines of code compared to 3 million... I think this is reason alone for it to be a separate package. I have this built as a Cygwin package using the default configure options at the moment. The only patch required was to Makefile.in (attached) to get it to stop appending .exe to the uxterm shell script. Thomas, can you recommend any configure options we should be using? I can think that the following might be useful: --enable-toolbar --enable-wide-chars --with-Xaw3d Any thoughts? Harold --- Makefile.in.orig2003-12-31 12:12:25.0 -0500 +++ Makefile.in 2004-03-18 16:17:56.842128000 -0500 @@ -139,14 +139,13 @@ actual_resize = `echo resize| sed '$(transform)'` binary_xterm = `echo xterm$x| $(TRANSFORM)` binary_resize = `echo resize$x| $(TRANSFORM)` -binary_uxterm = `echo uxterm| $(TRANSFORM)` install \ install-bin \ install-full :: xterm$x resize$x $(BINDIR) $(SHELL) $(srcdir)/sinstall.sh $(INSTALL_PROGRAM) xterm$x @XTERM_PATH@ $(BINDIR)/$(binary_xterm) $(INSTALL_PROGRAM) -s -m 755 resize$x $(BINDIR)/$(binary_resize) - $(INSTALL_SCRIPT) -m 755 $(srcdir)/uxterm $(BINDIR)/$(binary_uxterm) + $(INSTALL_SCRIPT) -m 755 $(srcdir)/uxterm $(BINDIR)/uxterm install \ install-man \ @@ -189,7 +188,7 @@ uninstall: -$(RM) $(BINDIR)/$(binary_xterm) -$(RM) $(BINDIR)/$(binary_resize) - -$(RM) $(BINDIR)/$(binary_uxterm) + -$(RM) $(BINDIR)/uxterm -$(RM) $(MANDIR)/$(actual_xterm).$(manext) -$(RM) $(MANDIR)/$(actual_resize).$(manext) -$(RM) $(APPSDIR)/$(CLASS)
Re: Upcoming X.org release and splitting packages
On Thu, 18 Mar 2004, Harold L Hunt II wrote: I have this built as a Cygwin package using the default configure options at the moment. The only patch required was to Makefile.in (attached) to get it to stop appending .exe to the uxterm shell script. Thomas, can you recommend any configure options we should be using? I can think that the following might be useful: --enable-toolbar that's broken (some incompatible changes to Xaw from XFree86 4.4 that I've not gotten around to investigating0. --enable-wide-chars you need this for uxterm --with-Xaw3d Some people like it. Actually all of the Xaw flavors look very much alike to me. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net
Re: Upcoming X.org release and splitting packages
On Thu, 18 Mar 2004, [ISO-8859-1] Frédéric L. W. Meunier wrote: Thomas, am (are) I (we) missing anything ? Are there any other options that are enabled or disabled in the xc version ? Perhaps --enable-luit (though I don't recall if anyone's mentioned using it with cygwin). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net
Re: Upcoming X.org release and splitting packages
bOn Thu, 18 Mar 2004, Thomas Dickey wrote: On Thu, 18 Mar 2004, Harold L Hunt II wrote: Frédéric L. W. Meunier wrote: What are the main differences between it and XFree86 4.4.0 ? Are things like XTerm 185 included, or everything that goes to XFree86 can't to X.org ? I don't know about XTerm 185 specifically, but this release should contain all fixes and features that were added to the XFree86 project's source code tree for the 4.4.0 release. xterm patch #185 is post-4.4, and according to fd.o's CVS is not in the release-1 branch. It may be worth to make it a separate package and start using your sources from http://invisible-island.net/xterm/ when they're newer (most of the time). -- http://www.pervalidus.net/contact.html
Re: Upcoming X.org release and splitting packages
Thomas Dickey wrote: On Thu, 18 Mar 2004, [ISO-8859-1] Fr?d?ric L. W. Meunier wrote: Thomas, am (are) I (we) missing anything ? Are there any other options that are enabled or disabled in the xc version ? Perhaps --enable-luit (though I don't recall if anyone's mentioned using it with cygwin). Hmm... good idea... I don't know if we have luit support or not. I would have to look into this. Harold
Re: Upcoming X.org release and splitting packages
Thomas Dickey wrote: On Thu, 18 Mar 2004, Harold L Hunt II wrote: I have this built as a Cygwin package using the default configure options at the moment. The only patch required was to Makefile.in (attached) to get it to stop appending .exe to the uxterm shell script. Thomas, can you recommend any configure options we should be using? I can think that the following might be useful: --enable-toolbar that's broken (some incompatible changes to Xaw from XFree86 4.4 that I've not gotten around to investigating0. Good to know. --enable-wide-chars you need this for uxterm Huh... this is disabled by default in my new build. I wonder if our old version had it enable or not. --with-Xaw3d Some people like it. Actually all of the Xaw flavors look very much alike to me. Same here. I could hardly tell the difference in xfig sometimes. Harold
Re: Upcoming X.org release and splitting packages
Frédéric L. W. Meunier wrote: On Thu, 18 Mar 2004, Harold L Hunt II wrote: Thomas Dickey wrote: However, I do make xterm patches more frequently than XFree86 releases occur - that's simply a matter of 60,000 lines of code compared to 3 million... I think this is reason alone for it to be a separate package. I have this built as a Cygwin package using the default configure options at the moment. The only patch required was to Makefile.in (attached) to get it to stop appending .exe to the uxterm shell script. Thomas, can you recommend any configure options we should be using? I can think that the following might be useful: --enable-toolbar --enable-wide-chars --with-Xaw3d Any thoughts? I think most are enabled by default. On Linux I only added --with-terminal-type=xterm-xfree86 --enable-256-color --enable-load-vt-fonts --disable-tek4014 --enable-toolbar --disable-vt52 --enable-luit. I'll have to see about those later... --enable-256-color sounds safe though. --with-terminal-type=xterm-xfree86 was just so I wouldn't get it set to xterm by default (lynx etc are black and white with it). I'm not sure this would be a good idea to change the default if we were not doing this before anyway. Then again, I would rather defer judgement on this one to someone with more knowledge on this subject. --disable-tek4014 --disable-vt52 seems to be recommend because it adds bloat and only a few people use it. Might not be a bad idea, but the .exe is only 233 KiB at the moment. It isn't exactly bloated. :) You can presumably replace the xc/program/xterm/ with xterm-185/ and the make World will use it. The idea here was to break xterm into its own package so it can be updated with more frequency and possibly handed off to someone else for maintenance. I have done this with the new 'xterm' package in setup.exe... should hit mirrors by tomorrow. I don't think --with-Xaw3d is worth, as it adds another dependency. Yes, that is why I guess I won't enable it for now. Harold
Re: Upcoming X.org release and splitting packages
On Thu, 18 Mar 2004, Harold L Hunt II wrote: Thomas Dickey wrote: However, I do make xterm patches more frequently than XFree86 releases occur - that's simply a matter of 60,000 lines of code compared to 3 million... I think this is reason alone for it to be a separate package. I have this built as a Cygwin package using the default configure options at the moment. The only patch required was to Makefile.in (attached) to get it to stop appending .exe to the uxterm shell script. Thomas, can you recommend any configure options we should be using? I can think that the following might be useful: --enable-toolbar --enable-wide-chars --with-Xaw3d Any thoughts? I think most are enabled by default. On Linux I only added --with-terminal-type=xterm-xfree86 --enable-256-color --enable-load-vt-fonts --disable-tek4014 --enable-toolbar --disable-vt52 --enable-luit. --with-terminal-type=xterm-xfree86 was just so I wouldn't get it set to xterm by default (lynx etc are black and white with it). --disable-tek4014 --disable-vt52 seems to be recommend because it adds bloat and only a few people use it. You can presumably replace the xc/program/xterm/ with xterm-185/ and the make World will use it. I don't think --with-Xaw3d is worth, as it adds another dependency. Thomas, am (are) I (we) missing anything ? Are there any other options that are enabled or disabled in the xc version ? -- http://www.pervalidus.net/contact.html
Re: Upcoming X.org release and splitting packages
On Fri, 19 Mar 2004, Harold L Hunt II wrote: Frédéric L. W. Meunier wrote: --with-terminal-type=xterm-xfree86 was just so I wouldn't get it set to xterm by default (lynx etc are black and white with it). I'm not sure this would be a good idea to change the default if we were not doing this before anyway. Then again, I would rather defer judgement on this one to someone with more knowledge on this subject. Question to Thomas: Why make xterm the default if all (?) ncurses applications run in black and white with it ? Sure, you can change .Xdefaults etc, but go figure. --disable-tek4014 --disable-vt52 seems to be recommend because it adds bloat and only a few people use it. Might not be a bad idea, but the .exe is only 233 KiB at the moment. It isn't exactly bloated. :) According to INSTALL: This reduces the executable size by 17% (checked 1999/3/13). Thomas should update it. I didn't notice 1/4 of it in the size. Maybe --disable-vt52 isn't worth. It isn't listed as bloat. You can presumably replace the xc/program/xterm/ with xterm-185/ and the make World will use it. The idea here was to break xterm into its own package so it can be updated with more frequency and possibly handed off to someone else for maintenance. I have done this with the new 'xterm' package in setup.exe... should hit mirrors by tomorrow. Sure. You just need to make sure all options enabled by a build with xmkmf are with one using configure. Isn't there an easy way to check ? At least here all options that were in my XFree86 build and I didn't disable in configure are reported by xterm --help / xterm -h. -- http://www.pervalidus.net/contact.html
Upcoming X.org release and splitting packages
We will soon (possibly next week) be releasing a new version of all Cygwin/X packages built from the source code tree managed by X.org and hosted on freedesktop.org. This will be a very good thing since all of the Cygwin/X developers will be able to stay in sync with the exact code that is in distribution via CVS, compared to our current system today where the code in distribution has many differences from that in CVS. The rebuild won't mean much to end users: all libraries remain binary compatible with the current packages and the contents of the release (programs, etc.) will be almost identical. In case you have not noticed, I created a build and packaging script system for Cygwin/X last week (took 60+ hours). This script system does a few things for us, such as allowing us to easily distribute source tarballs via Cygwin's setup.exe. More importantly, the script system allows us to exercise a finer control over what files each package contains and how many packages we break the distribution up into. We can very easily rename current packages when we make the next release, we can split existing packages into pieces, or we could take a set of packages, roll them back together, then split that entire mess into mixed pieces of the originals. I am mentioning this now because I can think of a few things that I would like to change in our package layout in time for the X.org release, but I would also like to get feedback from the community on what you think would be useful. Please take a look at my brief list of ideas below and send your thoughts to the mailing list if you have something about our packaging that you have wanted changed for a long time. My Proposals for Packaging Changes == 1) Due to popular demand, rename the prog package to devel. The name devel matches the defacto standard used by other packages for link libraries and header files; most people have no idea what the prog package is for, but they do know what a devel package is for. 2) Split the bin package into at least a few pieces (but not too many pieces): 2a) bin-dlls will contain the .dll files only. This would allow packages like emacs or xemacs to depend only on bin-dlls instead of on the entire bin package which includes programs not used by emacs nor xemacs. 2b) bin-lndir would contain the lndir utility. lndir has no dependence on X libs and can be used by any programmer for non-X projects. 2c) bin-apps would contain all other applications originally contained in bin but not contained in bin-dlls nor bin-lndir. 3) Rename all fonts packages from f100, cyr, fenc, fnts, fscl to something like fonts-100dpi, fonts-cyrillic, fonts-encodings, fonts-75dpi, and fonts-scalable. 4) Split the fnts package into a fonts-required and fonts-75dpi. fonts-required should be a very small package that would allow people to minimize their download if they are using Xdmcp to reach a KDE or Gnome desktop, both of which you client-rendered fonts (few fonts required on your Cygwin/X host in that case). 5) Rename the lib package to something more meaningful. The name currently implies that it might contain link libraries or run-time libraries, but it really contains files shared among X packages. Perhaps shared-files would be a better name. I would appreciate it if someone would look into what Debian and/or Fedora call this package. 6) Rename fsrv to font-server. 7) Rename html to manual-pages-html. 8) Rename man to manual-pages. Let us know what you think of those and send in your own suggestions as well. Harold
Re: Upcoming X.org release and splitting packages
Harold L Hunt II wrote: We will soon (possibly next week) be releasing a new version of all Cygwin/X packages built from the source code tree managed by X.org and hosted on freedesktop.org. This will be a very good thing since all of the Cygwin/X developers will be able to stay in sync with the exact code that is in distribution via CVS, compared to our current system today where the code in distribution has many differences from that in CVS. The rebuild won't mean much to end users: all libraries remain binary compatible with the current packages and the contents of the release (programs, etc.) will be almost identical. In case you have not noticed, I created a build and packaging script system for Cygwin/X last week (took 60+ hours). This script system does a few things for us, such as allowing us to easily distribute source tarballs via Cygwin's setup.exe. More importantly, the script system allows us to exercise a finer control over what files each package contains and how many packages we break the distribution up into. We can very easily rename current packages when we make the next release, we can split existing packages into pieces, or we could take a set of packages, roll them back together, then split that entire mess into mixed pieces of the originals. I am mentioning this now because I can think of a few things that I would like to change in our package layout in time for the X.org release, but I would also like to get feedback from the community on what you think would be useful. Please take a look at my brief list of ideas below and send your thoughts to the mailing list if you have something about our packaging that you have wanted changed for a long time. My Proposals for Packaging Changes == 1) Due to popular demand, rename the prog package to devel. The name devel matches the defacto standard used by other packages for link libraries and header files; most people have no idea what the prog package is for, but they do know what a devel package is for. +1 2) Split the bin package into at least a few pieces (but not too many pieces): 2a) bin-dlls will contain the .dll files only. This would allow packages like emacs or xemacs to depend only on bin-dlls instead of on the entire bin package which includes programs not used by emacs nor xemacs. 2b) bin-lndir would contain the lndir utility. lndir has no dependence on X libs and can be used by any programmer for non-X projects. 2c) bin-apps would contain all other applications originally contained in bin but not contained in bin-dlls nor bin-lndir. This sounds great... although I wonder whether it would be good to split bin-apps into bin-apps (xterm, xeyes, etc) and bin-utils (xauth, xhost etc) 3) Rename all fonts packages from f100, cyr, fenc, fnts, fscl to something like fonts-100dpi, fonts-cyrillic, fonts-encodings, fonts-75dpi, and fonts-scalable. +1 4) Split the fnts package into a fonts-required and fonts-75dpi. fonts-required should be a very small package that would allow people to minimize their download if they are using Xdmcp to reach a KDE or Gnome desktop, both of which you client-rendered fonts (few fonts required on your Cygwin/X host in that case). +1 5) Rename the lib package to something more meaningful. The name currently implies that it might contain link libraries or run-time libraries, but it really contains files shared among X packages. Perhaps shared-files would be a better name. I would appreciate it if someone would look into what Debian and/or Fedora call this package. Fedora has all the /usr/X11R6/lib/locale/ files, /usr/X11R6/lib/X11/rgb.txt /usr/X11R6/lib/X11/XErrorDB and /usr/X11R6/lib/X11/XKeysymDB in XFree86-libs-data, the /usr/X11R6/include/X11/bitmaps/ files in XFree86-devel, and on my system doesn't have /usr/X11R6/lib/X11/xedit/lisp/ files so I can't say. So I guess libs-data is a good name... 6) Rename fsrv to font-server. +1 7) Rename html to manual-pages-html. 8) Rename man to manual-pages. what about docs and docs-html for these too? Let us know what you think of those and send in your own suggestions as well. Harold Just some ideas David
Re: Upcoming X.org release and splitting packages
On Wed, 17 Mar 2004, Harold L Hunt II wrote: We will soon (possibly next week) be releasing a new version of all Cygwin/X packages built from the source code tree managed by X.org and hosted on freedesktop.org. This will be a very good thing since all of the Cygwin/X developers will be able to stay in sync with the exact code that is in distribution via CVS, compared to our current system today where the code in distribution has many differences from that in CVS. The rebuild won't mean much to end users: all libraries remain binary compatible with the current packages and the contents of the release (programs, etc.) will be almost identical. What are the main differences between it and XFree86 4.4.0 ? Are things like XTerm 185 included, or everything that goes to XFree86 can't to X.org ? 2) Split the bin package into at least a few pieces (but not too many pieces): 2a) bin-dlls will contain the .dll files only. This would allow packages like emacs or xemacs to depend only on bin-dlls instead of on the entire bin package which includes programs not used by emacs nor xemacs. Maybe do the same for Lesstif ? 2b) bin-lndir would contain the lndir utility. lndir has no dependence on X libs and can be used by any programmer for non-X projects. Nice. lndir is very useful when a /path/to/configure options doesn't work as expected due to lack of Automake support or brokeness. 2c) bin-apps would contain all other applications originally contained in bin but not contained in bin-dlls nor bin-lndir. I thought you'd split it more, like only adding what's really essential, and move xbiff, xclock, xedit, xman, etc to a separate package. But how to know what's essential ? And I guess imake, makedepend, /usr/X11R6/lib/X11/config, etc could go in devel ? -- http://www.pervalidus.net/contact.html
