This is the mail archive of the cygwin-xfree@cygwin.com 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: client runtime packaging request


Joe,

I agree, it would be nice if Cygwin/XFree86 packages were able to allow the user to pick-and-choose elements at a more fine-grained level.

Let me explain why this has not yet been done.

Our current method of creating Cygwin/XFree86 packages is to use the standard XFree86 packaging script (see the Contributor's Guide section on Pacakaging for more information) to build the standard set of XFree86 packages. These packages are all that the XFree86 project distributes and the list of packages for each platform, as well as what each package contains, are very nearly identical. If you look at the XFree86 ftp site you will notice that every distribution has essentially the same list of packages.

To create the Cygwin/XFree86 packages we just feed the standard XFree86 packages into a shell script that unpacks one or two packages at a time, adds maybe a file or two, and repacks the files into a package with the same, or nearly identical, name as the standard XFree86 packages.

This current method of creating packages does not require us to spend any time determining what files should go in which package, such as a GNU/Linux distribution might do with their own DEB or RPM packages for XFree86. All of these decisions are made for us by the standard XFree86 packaging script.

Most proposed changes to the packaging of Cygwin/XFree86 would require a paradigm shift in the way that Cygwin/XFree86 is packaged. We would have to have someone put in an initial 40 hours into developing a distribution framework (making sure no files are left out and that the layout is logical) and we would then have to have a commitment from someone to spend about 20 hours verifying that our packaging is correct each time the XFree86 project makes a new release (once or twice a year).

I cannot spend the time doing these additional tasks, and I have not received a promise to take on these tasks from anyone. Thus, the packaging system will remain largely unchanged for now.

If anyone is considering taking on these tasks, note this: a promise to do good work is not so good as doing good work first (like designing, implementing, and testing a new package layout) and then offering that work for review. I tend to put a lot more trust in someone's promise when they have already done 20 to 40 hours of work. In other words, don't bother replying to say, ``hey, I can help with that.'' I have heard those sorts of promises all too often.


Joe, in specific regards to your request: your change may not be that difficult, but I do not have time to look into it right now. Our DLL files are not a part of standard XFree86 distributions, so it may just be that they have slipped into the wrong package by accident. I would appreciate it if someone would look into whether or not there is a better package for these DLLs (choose from amoung the list of existing packages). It may be best to stick these in the lib package, which is quite small if I recall correctly, and add the lib package to the required packages in XFree86-base.


I hope that clears things up. It isn't that our current package system is the best, it is just that it is the easiest to maintain.


Harold


Joe Buehler wrote:
I recently ported GNU emacs to Cygwin.  It would help reduce the
disk space requirements if some refinement was done on the xfree
packaging.

The particular thing that is immediately obvious is that the dll's that
emacs requires are in the XFree86-bin package, along with a *lot*
of other stuff that emacs does not require.

A base runtime package that contains only those things that an X11 client
needs would be mighty nice.  Config files, fonts, dll's, etc.

Joe Buehler







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