From: Chris S. <ir0...@gm...> - 2011-11-14 02:57:30
|
By request, I've packaged mksh for MSYS (and the mksh developers have been very pro-active in tweaking mksh for MSYS). Taking advantage of Chuck's mgwport utility, it was easy to modify my mksh cygport for msys (thanks Chuck). Given how things have been re-organized on FRS, I assume this should be part of MSYS/Extension? Chuck, what's the policy on the xml manifest files? Are they to be included, like setup.hint in the MSYS_PATCHES directory? Cheers, Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Charles W. <cwi...@us...> - 2011-11-14 03:18:30
|
On 11/13/2011 9:57 PM, Chris Sutcliffe wrote: > By request, I've packaged mksh for MSYS (and the mksh developers have > been very pro-active in tweaking mksh for MSYS). Taking advantage of > Chuck's mgwport utility, it was easy to modify my mksh cygport for > msys (thanks Chuck). That's what it was for; glad it was of use. > Given how things have been re-organized on FRS, > I assume this should be part of MSYS/Extension? I think the key determinant between "Contributed" and "Extension" is whether the core MinGW/MSYS team commit to practically perpetual support for the package. This gets a bit tricky when the contributor is *one of* the core team... E.g. if you get hit by a bus, do the rest of us agree that mksh is important enough for one of us to continue updating the package? (It's actually possible that a few of the items currently in Extension don't meet that test, so maybe it's a bit /too/ stringent.) I think we'd all agree that say, "cvs", "ssh", or "bison" fit the bill, but ... We're still kindof feeling our way forward on this, so don't take this as a "no" -- or a "yes". I'm really just thinking out loud, here. > Chuck, what's the policy on the xml manifest files? Are they to be > included, like setup.hint in the MSYS_PATCHES directory? Well, anything that's part of Core or Extension, has the "real" manifest maintained in the mingw-dist repo. I went ahead and added mgwport's manifest to its package, too -- but that's probably overkill. I bet that I eventually get tired of maintaining both copies, and remove the "internal" one at some point. For other packages -- Contributed ones -- I don't think we have a policy. Whatever the Contributor wants, I suppose. Unlike cygport+setup.hint and the "dist/" subdirectory, mgwport knows nothing about manifest xml files. -- Chuck |
From: Earnie <ea...@us...> - 2011-11-14 12:27:29
|
Charles Wilson wrote: > On 11/13/2011 9:57 PM, Chris Sutcliffe wrote: >> By request, I've packaged mksh for MSYS (and the mksh developers have >> been very pro-active in tweaking mksh for MSYS). Taking advantage of >> Chuck's mgwport utility, it was easy to modify my mksh cygport for >> msys (thanks Chuck). > > That's what it was for; glad it was of use. > >> Given how things have been re-organized on FRS, >> I assume this should be part of MSYS/Extension? > > I think the key determinant between "Contributed" and "Extension" is > whether the core MinGW/MSYS team commit to practically perpetual support > for the package. This gets a bit tricky when the contributor is *one > of* the core team... > My opinion is that we should put it in contributed. We can judge the use by the download count and make a determination later if we want to move it to Extension. > E.g. if you get hit by a bus, do the rest of us agree that mksh is > important enough for one of us to continue updating the package? (It's > actually possible that a few of the items currently in Extension don't > meet that test, so maybe it's a bit /too/ stringent.) I think we'd all > agree that say, "cvs", "ssh", or "bison" fit the bill, but ... > > We're still kindof feeling our way forward on this, so don't take this > as a "no" -- or a "yes". I'm really just thinking out loud, here. > Yea, we need to review still. I don't think everything we have in extension belongs there. I'll create an RFC later to discuss this on a per package list. >> Chuck, what's the policy on the xml manifest files? Are they to be >> included, like setup.hint in the MSYS_PATCHES directory? > > Well, anything that's part of Core or Extension, has the "real" manifest > maintained in the mingw-dist repo. I went ahead and added mgwport's > manifest to its package, too -- but that's probably overkill. I bet > that I eventually get tired of maintaining both copies, and remove the > "internal" one at some point. > We need to be able to use mingw-get to install it. > For other packages -- Contributed ones -- I don't think we have a > policy. Whatever the Contributor wants, I suppose. Unlike > cygport+setup.hint and the "dist/" subdirectory, mgwport knows nothing > about manifest xml files. > Unfortunate but understandable. We do need a utility that can generate the xml for the package. I don't think we want to accept any new packages that can't be installed by mingw-get. Earnie |
From: Charles W. <cwi...@us...> - 2011-11-14 13:28:22
|
On 11/14/2011 7:27 AM, Earnie wrote: > Charles Wilson wrote: >> On 11/13/2011 9:57 PM, Chris Sutcliffe wrote: >>> Chuck, what's the policy on the xml manifest files? Are they to be >>> included, like setup.hint in the MSYS_PATCHES directory? >> >> Well, anything that's part of Core or Extension, has the "real" manifest >> maintained in the mingw-dist repo. I went ahead and added mgwport's >> manifest to its package, too -- but that's probably overkill. I bet >> that I eventually get tired of maintaining both copies, and remove the >> "internal" one at some point. >> > > We need to be able to use mingw-get to install it. That's not at issue. What Chris is asking is, should foo-1.2.3-4-mingw32-{bin or doc or $what}.tar.lzma actually contain an internal copy of the manifest, or should $contributor simply manage a private version which he asks us to upload to Installer/mingw-get/catalogue at the same time he asks us to upload new tarballs? I lean toward the latter, unless the contributor simply WANTS to ship a copy of the .xml inside one of the tarballs. -- Chuck |
From: Keith M. <kei...@us...> - 2011-11-14 18:57:41
|
On 14/11/11 13:28, Charles Wilson wrote: >> We need to be able to use mingw-get to install it. > > That's not at issue. What Chris is asking is, should > foo-1.2.3-4-mingw32-{bin or doc or $what}.tar.lzma actually contain an > internal copy of the manifest, If it's to be bundled, (and I lean toward doing so), then the logical place is the SOURCE tarball, along with other MinGW specific patches and similar files. > or should $contributor simply manage a private version which he asks > us to upload to Installer/mingw-get/catalogue at the same time he > asks us to upload new tarballs? He should do this anyway; any bundled copy in -src should be viewed as a convenience for any other contributor who may wish to work further on his original contribution. Thus... > I lean toward the latter, unless the contributor simply WANTS to ship a > copy of the .xml inside one of the tarballs. It mostly boils down to contributor's choice, but my preference would be to see it bundled with -src. -- Regards, Keith. |
From: Chris S. <ir0...@gm...> - 2011-11-15 12:42:23
|
On 14 November 2011 13:57, Keith Marshall wrote: > On 14/11/11 13:28, Charles Wilson wrote: >>> We need to be able to use mingw-get to install it. >> >> That's not at issue. What Chris is asking is, should >> foo-1.2.3-4-mingw32-{bin or doc or $what}.tar.lzma actually contain an >> internal copy of the manifest, > > If it's to be bundled, (and I lean toward doing so), then the logical > place is the SOURCE tarball, along with other MinGW specific patches and > similar files. I agree that if the xml manifest file is to be bundled, it should be in the source package. I don't necessarily agree with bundling it though. Given the scenario where there is an error in the xml file or something changes in mingw-get that requires a modification to the xml, in theory you should re-package the entire solution in order to pick-up the new manifest. This seems like a lot of overhead effort for a potentially minor change. If someone decides to take ownership of a given package, the latest xml file is available in the FRS under the catalogue, or for that matter, is in their mingw-get cache, so I don't see the benefit of bundling it. Cheers, Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Charles W. <cwi...@us...> - 2011-11-15 13:51:54
|
On 11/15/2011 7:42 AM, Chris Sutcliffe wrote: > I don't necessarily agree with bundling it > though. Given the scenario where there is an error in the xml file or > something changes in mingw-get that requires a modification to the > xml, in theory you should re-package the entire solution in order to > pick-up the new manifest. This seems like a lot of overhead effort > for a potentially minor change. > > If someone decides to take ownership of a given package, the latest > xml file is available in the FRS under the catalogue, or for that > matter, is in their mingw-get cache, so I don't see the benefit of > bundling it. I agree with Chris, with regards to the complete manifest. However, if mgwport were to incorporate, as an optional step, Keith's nroff tools for generating that manifest on the fly from "pieces" then it would make sense for those pieces to be bundled in the -src package. /How/ exactly, would depend on the implementation of Keith's tools within mgwport. I'll give it some thought. However, if the manifest is maintained by hand, Chris is right -- there's no reason an adopter can't simply adopt the latest version from the FRS. -- Chuck |
From: Chris S. <ir0...@gm...> - 2011-11-15 17:08:37
|
With respect to the manifest file for mksh, do I commit it to CVS (I noticed the libunistring manifest was not)? Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Charles W. <cwi...@us...> - 2011-11-15 17:24:52
|
On 11/15/2011 12:08 PM, Chris Sutcliffe wrote: > With respect to the manifest file for mksh, do I commit it to CVS (I > noticed the libunistring manifest was not)? If it is part of -Base or -Extension, then yes. If -Contrib, then no -- only msys-package-list.xml(?) and issue.log are updated. -- Chuck |
From: Keith M. <kei...@us...> - 2011-11-15 20:15:20
|
On 15/11/11 17:24, Charles Wilson wrote: > On 11/15/2011 12:08 PM, Chris Sutcliffe wrote: >> With respect to the manifest file for mksh, do I commit it to CVS (I >> noticed the libunistring manifest was not)? > > If it is part of -Base or -Extension, then yes. If -Contrib, then no -- > only msys-package-list.xml(?) and issue.log are updated. And issue.log only wrt the change to msys-package-list.xml; this will be automatic, when you rebuild after adding the new reference in the package list file. -- Regards, Keith. |
From: Keith M. <kei...@us...> - 2011-11-15 22:03:38
|
On 15/11/11 13:51, Charles Wilson wrote: > On 11/15/2011 7:42 AM, Chris Sutcliffe wrote: >> I don't necessarily agree with bundling it >> though. Given the scenario where there is an error in the xml file or >> something changes in mingw-get that requires a modification to the >> xml, in theory you should re-package the entire solution in order to >> pick-up the new manifest. This seems like a lot of overhead effort >> for a potentially minor change. Good point. >> If someone decides to take ownership of a given package, the latest >> xml file is available in the FRS under the catalogue, or for that >> matter, is in their mingw-get cache, so I don't see the benefit of >> bundling it. > > I agree with Chris, with regards to the complete manifest. Having given it further thought, I agree too. > However, if mgwport were to incorporate, as an optional step, Keith's > nroff tools for generating that manifest on the fly from "pieces" ... Pieces? There is one generator script, which mgwport could incorporate as a module, invoking its code in response to a request to execute a new (call it, say) mkxml action; (at least that's how *my* scripts do it). This generator script gets all the information it needs from only one place -- the .pkgspec file in my case, for which your equivalent would be the .mgwport or .msysport file. > then it would make sense for those pieces to be bundled in the -src > package. /How/ exactly, would depend on the implementation of > Keith's tools within mgwport. I'll give it some thought. Sure. I'll leave the details to your discretion. > However, if the manifest is maintained by hand, Chris is right -- > there's no reason an adopter can't simply adopt the latest version > from the FRS. Agreed. -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2011-11-15 22:08:46
|
On 11/15/2011 5:03 PM, Keith Marshall wrote: > On 15/11/11 13:51, Charles Wilson wrote: >> However, if mgwport were to incorporate, as an optional step, Keith's >> nroff tools for generating that manifest on the fly from "pieces" ... > > Pieces? There is one generator script, which mgwport could incorporate > as a module, invoking its code in response to a request to execute a new > (call it, say) mkxml action; (at least that's how *my* scripts do it). > This generator script gets all the information it needs from only one > place -- the .pkgspec file in my case, for which your equivalent would > be the .mgwport or .msysport file. Oh, okay. I misinterpreted; I thought the output was assembled from snippets, in multiple files, that were pasted together with perhaps some $string interpolation/replacement. I should probably look at the actual implementation before assuming stuff, huh? >> then it would make sense for those pieces to be bundled in the -src >> package. /How/ exactly, would depend on the implementation of >> Keith's tools within mgwport. I'll give it some thought. > > Sure. I'll leave the details to your discretion. :-) -- Chuck |
From: Keith M. <kei...@us...> - 2011-11-16 20:44:22
|
On 15/11/11 22:03, Keith Marshall wrote: > On 15/11/11 13:51, Charles Wilson wrote: >> On 11/15/2011 7:42 AM, Chris Sutcliffe wrote: >>> I don't necessarily agree with bundling it >>> though. Given the scenario where there is an error in the xml file or >>> something changes in mingw-get that requires a modification to the >>> xml, in theory you should re-package the entire solution in order to >>> pick-up the new manifest. This seems like a lot of overhead effort >>> for a potentially minor change. > > Good point. > >>> If someone decides to take ownership of a given package, the latest >>> xml file is available in the FRS under the catalogue, or for that >>> matter, is in their mingw-get cache, so I don't see the benefit of >>> bundling it. >> >> I agree with Chris, with regards to the complete manifest. > > Having given it further thought, I agree too. However, an option which may be worth considering: rather than bundling it within any component of the main package, provide a *supplementary* package comprising: - The XML file in *template* form; (i.e. with issue="@YYYYMMDDNN@"); - A date stamp (%.issue) file for the most recently generated issue; - A makefile, derived from the sample I posted previously. Such a supplementary package could be managed independently of the package to which it relates, (just as we do in the case of mingw-dist), so avoiding the repackaging overhead which is of concern here. Certainly, you may argue,(and you would be right), that having the sample makefile to hand, together with the current XML file from FRS, it should be fairly easy to reverse engineer such a supplementary package. Thus, such a package may be considered as an optionally provided convenience, rather than as a mandatory requirement. -- Regards, Keith. |
From: Keith M. <kei...@us...> - 2011-11-14 18:47:25
|
On 14/11/11 12:27, Earnie wrote: >>> Given how things have been re-organized on FRS, >>> I assume this should be part of MSYS/Extension? >> >> I think the key determinant between "Contributed" and "Extension" is >> whether the core MinGW/MSYS team commit to practically perpetual support >> for the package. This gets a bit tricky when the contributor is *one >> of* the core team... > > My opinion is that we should put it in contributed. I agree. > We do need a utility that can generate the xml for the package. I already gave you that, when we were discussing Erwin's libunistring contribution -- yes, it would need to be adapted for mgwport, since as I provided it, it derives its content from a more Slackware-like, (and IMO, more human-readable), package specification. (Actually, it likely wouldn't take too much effort for mgwport to comprehend specs in such a format, which may be advantageous). -- Regards, Keith. |
From: Earnie <ea...@us...> - 2011-11-14 19:00:29
|
Keith Marshall wrote: > On 14/11/11 12:27, Earnie wrote: >>>> Given how things have been re-organized on FRS, >>>> I assume this should be part of MSYS/Extension? >>> >>> I think the key determinant between "Contributed" and "Extension" is >>> whether the core MinGW/MSYS team commit to practically perpetual support >>> for the package. This gets a bit tricky when the contributor is *one >>> of* the core team... >> >> My opinion is that we should put it in contributed. > > I agree. > >> We do need a utility that can generate the xml for the package. > > I already gave you that, when we were discussing Erwin's libunistring > contribution -- yes, it would need to be adapted for mgwport, since as I > provided it, it derives its content from a more Slackware-like, (and > IMO, more human-readable), package specification. (Actually, it likely > wouldn't take too much effort for mgwport to comprehend specs in such a > format, which may be advantageous). > The "we" is inclusive of the MinGW community as a whole. There isn't a deliverable by mingw-get package to do this as yet. Earnie |
From: Keith M. <kei...@us...> - 2011-11-14 19:22:56
|
On 14/11/11 19:00, Earnie wrote: >>> We do need a utility that can generate the xml for the package. >> >> I already gave you that, when we were discussing Erwin's libunistring >> contribution -- yes, it would need to be adapted for mgwport, since as I >> provided it, it derives its content from a more Slackware-like, (and >> IMO, more human-readable), package specification. (Actually, it likely >> wouldn't take too much effort for mgwport to comprehend specs in such a >> format, which may be advantageous). > > The "we" is inclusive of the MinGW community as a whole. There isn't a > deliverable by mingw-get package to do this as yet. Well, IMO the appropriate delivery vehicle is via mgwport integration, (unless you want YAPT, based on my private -- and much simpler -- set of packaging scripts. I, for one, don't really want to get into a packaging tool contest with Chuck, even if I do prefer some aspects of my own scripts). -- Regards, Keith. |
From: Earnie <ea...@us...> - 2011-11-14 14:41:27
|
Charles Wilson wrote: > On 11/14/2011 7:27 AM, Earnie wrote: >> Charles Wilson wrote: >>> On 11/13/2011 9:57 PM, Chris Sutcliffe wrote: >>>> Chuck, what's the policy on the xml manifest files? Are they to be >>>> included, like setup.hint in the MSYS_PATCHES directory? >>> >>> Well, anything that's part of Core or Extension, has the "real" manifest >>> maintained in the mingw-dist repo. I went ahead and added mgwport's >>> manifest to its package, too -- but that's probably overkill. I bet >>> that I eventually get tired of maintaining both copies, and remove the >>> "internal" one at some point. >>> >> >> We need to be able to use mingw-get to install it. > > That's not at issue. What Chris is asking is, should > foo-1.2.3-4-mingw32-{bin or doc or $what}.tar.lzma actually contain an > internal copy of the manifest, or should $contributor simply manage a > private version which he asks us to upload to > Installer/mingw-get/catalogue at the same time he asks us to upload new > tarballs? > > I lean toward the latter, unless the contributor simply WANTS to ship a > copy of the .xml inside one of the tarballs. > Oh, yea, me too. On the other hand a contributor could create a massive tar containing all the components so we have only one file to download but that might get messy. Earnie |
From: Charles W. <cwi...@us...> - 2011-11-14 15:44:34
|
On 11/14/2011 9:40 AM, Earnie wrote: > On the other hand a contributor could create a massive > tar containing all the components so we have only one file to download > but that might get messy. mgwport deposits all of the .tar.lzma in a subdirectory for easy upload -- or mega tarball creation. foo-1.2.3-1/dist/$PKG/<tarballs here> When uploading *cygwin* packages to sourceWARE, I generally cd to dist/ and tar up $PKG, scp to sourceware, then log in and unpack. But...that requires shell access, which is a bit awkward @ sourceFORGE. So, given that -- if I have to individually upload via scp each .tar.lzma (from my home pc to frs), I might as well also individually download them (from the contributor's site to my home pc). -- Chuck |