Steffen Sledz wrote: > Hmmm? I'm not sure if this is a practical solution because the old > emacs-leim package is just obsolete, if a new emacs package is > installed. How can i describe this inter-package dependency?
There's no way to express any version specific requirements. Once the old emacs package gets demoted to [prev], it becomes a second class citizen. In order to use it the user would have to know to set 'emacs' to [prev] as well as 'emacs-leim' to [prev] as well (you can state this in the release announcement.) Or in other words, upgrading to the v22 emacs package should have the effect of also uninstalling v21 emacs-leim, which is accomplished by installing the new [curr] of both packages. Here I'm assuming that having a v22 emacs and a v21 emacs-leim both installed at the same time causes breakage. You should assume that all users use [curr] versions for all desired packages, or at least [curr] as of the install date, not necessarily [curr] as of the current date, and that any user that selects any [prev] or [exp] version knows exactly what they are doing and are prepared for breakage. The setup program and the ini file grammar just do not give us the freedom to properly express all the required metadata to support anything else. There's no way to express "foo version X requires bar, but foo version X+1 does not" nor "foo version X requires bar version Y and not version Y-1". I suppose an alternative might be to just not touch the 'emacs-leim' package at all, since it looks like it's not required by anything explicitly so it must be purely optional. But then users have to know that if they have v21 emacs-leim installed they must uninstall it before installing the v22 emacs package, and that's not friendly. Again preference should always go to users using straight [curr], not users who want to use a version that is [prev]; so this is a bad idea. > And a last question: It's not fully clear to me what's the best mailing > list to ask for problems maintaining e.g. the emacs packages or looking > for testers? cygwin? or cygwin-apps? cygwin-apps@ is for threads about creating packages, maintaining packages, reviewing the packaging of packages, requesting uploads of packages, taking over maintainership of packages, etc. In other words THIS THREAD! cygwin@ is for everything else, including user reports of difficulties using a package. As far as asking for testers, I suppose technically that should go on -apps but there isn't very wide readership there compared to the main list so it could probably go either way. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
