This is the mail archive of the cygwin-apps mailing list for the Cygwin 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] |
On Dec 8 19:30, Jon Turney wrote: > On 30/08/2016 13:24, Jon Turney wrote: > > This file is called override.hint. > > While not a great deal of use is made of test versions, this mechanism > doesn't seem to be working well for that, and there have been several > requests to improve it. > > There's no automation to generate override.hint, and writing it correctly > requires too much knowledge about how calm is going to process it. > [...] ACK. It's kind of backwards compared to the new layout with per-version hint files. > The proposal to address this is: > > Add support to calm for a 'test:' line in PVR.hint, marking a version as a > test version. ACK > If multiple versions are marked test, the highest version will be used as > the test version in the generated setup.ini (and thus offered for > installation using the 'exp' control in setup.) > > (Note to self: why isn't this control labelled 'test', which is an actual > english word???) Note to jturney, change it, don't be shy. > Versions marked as test cannot be used as curr: (so test versions are never > automatically promoted to curr) > > override.hint will continue to work, and, if one exists it takes precedence > over these rules. I would rather drop it as an evolutionary dead end. > cygport will be updated to (details TBC) accept a --test flag which is > significant to the cygport package stage, and adds this 'test:' line to all > the generated PVR.hint files. --test would be fine. > To promote a package from test to curr, a script will be run on sourceware > to remove the test: line from the existing PVR.hints in a given package > subtree, for a given VR. > > Since this requires shell access on sourceware, if you don't have that, you > can ask here or on #cygwin-developers. I don't think this is feasible. The maintainer should have control over the promotion from test to curr. I'm not affected by this since I generate new versions as soon as I promote, so this is more maintainers like JonY, for whom a rebuild and reupload of the gcc packages just to promote test to curr is quite a burden. First, not well thought out proposal: - cygport gets a new command, e. g. cygport foo.cygport {promote|untest|currify} This command has only one purpose. It uploads a file !untest to the maintainers upload area, with a single line containing the version number from the foo.cygport file, i. e. - Fetch $PVR from foo.cygport, e. g. 2.24-1. - echo "$PVR" > !untest - lftp !untest to cygwin.com:maintainer-area - While creating the ini file, calm looks for !untest files. If one is available, check the version number. If there's a matching PVR.hints file, drop the test marker. Continue with creating the ini file. > I would like to provide an automatic mechanism to allow package maintainers > to promote their own test packages, but there are a few stumbling blocks in > the way of that, currently. -v? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Attachment:
signature.asc
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |