From: Earnie <ea...@us...> - 2011-08-12 14:43:30
|
Keith Marshall wrote: > On 11/08/11 19:46, Charles Wilson wrote: >>> My intention is that it should unpack into the user's current working >>> directory. (I'm assuming that the top level directory within the source >>> tarball itself will result in the creation of an appropriately named >>> package specific subdirectory, below CWD). >> >> Very few of them do that, at present. > > Any which I have packaged do. > >> Most contain something like this: >> >> buildscript >> patchfile(s) >> original-source-tarball > > Ouch! > >> After installing a dozen of these, things can get pretty confusing. > > I guess it would, but it's worse than that. These aren't true source > packages at all; they are wrapper packages, with the real source packed > at an extra level of indirection within them. IMO, such packages are > malformed; they are certainly incompatible with my current concept of > how "mingw-get source ..." should work. > > I think we should move this discussion to MinGW-dvlpr. My preference > would be to bite the bullet, and repackage the source tarballs with a > more appropriate structure. I'm suspending this line of development > until we can agree how we should move this forward. > Moved to the developer list. I've tended not to like Chuck's style of source deliver either. I would rather see the patched source be delivered in the -src file and if need be the configure/build options given in the README file. I've lived with the delivery method because I know how to patch but I've found it inconvenient. -- Earnie -- http://www.for-my-kids.com |
From: Charles W. <cwi...@us...> - 2011-08-12 17:27:03
|
Beware. Long History And Rant Follows. This thread was about how the 'source' action should operate -- but became a criticism of how I've packaged source, with hints of "biting the bullet" and spending hundreds of hours (of my time) repackaging to satisfy cosmetic objections. Hell, it takes about 30 minutes just to manage the uploading process for a single packageset, when you account for modifying the manifests, rebuilding, uploading the .xml.lzma, then uploading the tarballs themselves...multiply by 100 -src packages and you're at 50 hours before you even do any compiling. Short version: the source action can do whatever Keith wants -- he's writing the code and I'll adapt. But hell no to following some arbitrary new standard just because somebody else has non-technical, non-legal, but merely cosmetic objections to current practice. On 8/12/2011 10:43 AM, Earnie wrote: > Keith Marshall wrote: >> On 11/08/11 19:46, Charles Wilson wrote: >>> Most contain something like this: >>> >>> buildscript >>> patchfile(s) >>> original-source-tarball >> >> Ouch! >> >>> After installing a dozen of these, things can get pretty confusing. >> >> I guess it would, but it's worse than that. These aren't true source >> packages at all; they are wrapper packages, with the real source packed >> at an extra level of indirection within them. IMO, such packages are >> malformed; they are certainly incompatible with my current concept of >> how "mingw-get source ..." should work. Malformed? That's your debian-centric view. RPM-based distros, as well as gentoo and other source-based ones, package source as I have done: pristing source, a series of patches, and a driver script of some sort (e.g. rpm.spec). I've been maintaining dozens of packages for cygwin for over 10 years. In the beginning, things were rather a hodge-podge; every maintainer did it their own way, and there was little commonality. Eventually things settled down organically -- in general, things were (mostly) done in a debian-like manner -- see http://cygwin.com/setup.html#package_contents, package source, method one. In short, everything cygwin-ish was stuffed into a subdir of the cygwin "-src" tarball, which incorporated the original (patched, if necessary) source: foo-$VER/configure.ac foo-$VER/Makefile.am foo-$VER/<other> foo-$VER/CYGWIN-PATCHES/foo.README (cygwin release notes) foo-$VER/CYGWIN-PATCHES/setup.hint (cygwin package manager info) foo-$VER/CYGWIN-PATCHES/foo.patch (*) foo-$VER/CYGWIN-PATCHES/>other> (*) This "foo.patch" could be applied (with -R) to *remove* all cygwin customizations from the source dir, leaving something identical to the original upstream foo-$VER.tar.gz, except for foo.patch itself. The point is the cygwin src package, once unpacked, is ALREADY patched for building on cygwin. So you see, this is very similar to the debian structure, where <srcdir>/debian/ contains patch files, build driver scripts, etc. However, in debian the patches are not pre-applied; the "tool" (external, in debian's case, although it uses the <src>/debian/rules file(s) to control its operation). The problem with this procedure was recursion. You couldn't create foo.patch while foo.patch was present in tree (ever looked at debian's changes? a bunch of patches that CREATE patches...ick). So, to regenerate it, you had to move the existing one away, do the diff, then copy the result back in. Plus, there was no standardized build "recipe" or build script, so it was difficult for one maintainer to "take over" a package -- or release an update in an emergency situation -- if the original maintainer was AWOL for some reason. So, cygwin's original mechanism for supplying source was VERY similar to (a) debian, and (b) mingwPORT. But the awkwardness of it -- AND mingwPORT -- soured my view of debian-like package management from package maintainer's POV. This structure -- pre-patched source that unpacks already modified (or a "build procedure" that unpacks the pristine source "around" the build driver files, a la mingwPORT) makes it difficult to maintain, or to forward port changes to new releases. "patch" files stored *under* the top level source directory means icky recursion issues when diff'ing from upstream to verify that yes, those patches really DO express ALL the differences between the platform-customized and upstream sources. etc. So then, cygwin developed the "generic-build-script". http://sourceware.org/cgi-bin/cvsweb.cgi/~checkout~/packaging/templates/generic-build-script?content-type=text/plain&cvsroot=cygwin-apps The "-src" package (after patching) had an internal layout like this: foo-$VER/<source stuff> foo-$VER/CYGWIN-PATCHES/build-script (here, OR outside dir) foo-$VER/CYGWIN-PATCHES/packaging extras (like setup.hint) and the cygwin "-src" package unpacked to: foo-$VER.sh (build script here OR in foo-$VER/CYGWIN-PATCHES/) foo-$VER.patch (ALL changes: source, "packaging" files, etc) foo-$VER.tar.bz2 and you'd run "foo-$VER.sh <args>". This had (has) its problems, but near universal adoption by almost all of the cygwin package maintainers demonstrates that it was FAR preferable to the previous debian/mingwPORT-like mechanism for source packages. (Cygwin never imposes a requirement that sources be delivered in any one way or another; so adoption of any tool or standard is purely voluntary. gbs's almost immediate near-universal adoption is informative). You can see the obvious parallels between cygwin gbs and many of the msys packages I've delivered. (Most of the *mingw* packages were done as pseudo mingwPORTS, but I'm slowly changing them over to msysrlsbld-driven ones -- although that's jumping ahead in the story). One thing BOTH of the preceding cygwin packaging standards had in common was that everything needed to build the package was delivered WITH the -src tarball. E.g. the build driver script (by whatever name) in "method one", a customized version of gbs in method two, etc. This is similar, in some ways, to our current mingwPORT: you grab a copy of the most recent "generic" build script (or mingwPORT source), and then modify it for package foo -- and the whole thing is delivered; no external tools (other than gcc, wget, binutils, etc) needed. One of the problems with this is that it is hard to collaborate: if Bob provides a great new feature for the generic-build-script (or mingwPORT), it's difficult for me to use it with foo-$NEXT. I've already changed so much in foo-$CURR's build script (or mingwPORT) that it's hard for me to figure out how to adapt my changes to both the needs of foo-$NEXT and gbs-$NEXT. Eventually, on cygwin, the "cygport" tool was created. Similar to gentoo's ebuild (or rpm's rpmbuild), this tool is installed *separately* from any given source package. Then, source packages could deliever a simple driver script that sets a few vars, perhaps overrides a few shell functions, to customize only what's necessary for package foo. So, taking advantage of "upstream" improvements in the "build script" became much easier. And, writing a "foo.cygport" file was MUCH easier than customizing generic-build-script. So, almost overnight, it replaced gbs entirely -- again, by individual developer choice. Recently, cygport has gained the ability to drive a build as a cross-compile -- e.g. running on linux, with a suitable cygwin-target compiler, to create cygwin packages. (Also, since 0.10.0, has supported building cross-compiler and cross-compiled (cygwin->foo) packages ON cygwin.) Cesar's msysrlsbld draws inspiration from both gbs and cygport. It differs in that (a) it doesn't support, OOB, as many different build systems, and (b) it is much simpler, so the core msysrlsbuild script is delivered in toto with each -src package. However, customizations are done in a separate config file, msysrlsbld.ini -- so hopefully updating to the "latest and greatest" msysrlsbld is easy (if the dev followed the rules, and only modified the .ini). In summary, ALL of these methods, except the first, supplied 1) a pristine upstream src tarball 2) patches 3) driver script and were ALL deemed, by freely-chosen adoption by many different devs, to be superior to the earlier, primitive debian approach. Now, PERHAPS, were there to exist an external "debbuild"-like package, which provided the tools to manipulate source packages delivered according to the debian-like standard Keith appears to prefer, THEN maybe that delivery structure would be more attractive. But there isn't. So it isn't. >> I think we should move this discussion to MinGW-dvlpr. My preference >> would be to bite the bullet, and repackage the source tarballs with a >> more appropriate structure. Appropriate? According to who? The Gods of Debian? Frankly, debian's source structure sucks. I've used (something very similar to) it, and I hated it. It was a fracking pain in the *ss. >> I'm suspending this line of development >> until we can agree how we should move this forward. I really don't see what the problem is. Any choice is fine, really. Either (a) unpack directly to the <cwd>/ as you proposed originally. In this case, the user will soon learn, with many current -src packages, that it's best to: $ mkdir foo-working $ cd foo-working $ mingw-get source --unpack msys-bob and if it's not necessary -- e.g. debian-style packaging -- then all they've lost is two commands and an extra level of dir depth. (b) unpack directly to a standard dir like /usr/src. Sure, if you do that a lot, then your /usr/src could get cluttered. So, with my packages you keep /usr/src clean by doing this: $ mkdir /usr/local/src/mingw-foo $ mingw-get source --unpack mingw-foo $ mv /usr/src/* /usr/local/src/mingw-foo Note that RPMS do exactly this (except there's no opportunity for cleanup) -- SRPMS are all "installed" directly in /usr/src/RPMS/SRPMS/ so you've got a bunch of .spec and .patch files from multiple packages all in the same dir. It's ugly but hasn't broken anything yet. (c) have mingw-get create a standard dir name from the -src package name; mingw32-foo-$VER, perhaps. Doesn't need to be the ENTIRE package spec; the odds of clobbering are pretty low. Unpack into that -- either below <cwd> or a standard dir like /usr/src. For my packages, this is great. For debian-style packages, you end up with an extra level of directory -- which isn't terrible, since you'll inevitably have to grab the REAL source tarball, and unpack it somewhere, to regenerate any patches if you make changes: <cwd>/mingw32-foo-$VER/ <cwd>/mingw32-foo-$VER/foo-$VER/ <debian style stuff> --- eventually, you'll need to create --- <cwd>/mingw32-foo-$VEr/foo-$VER-orig/ <upstream src> --- and you'll want a place to temporarily store patches, --- and have a build directory, and possibly a temp inst --- dir. It makes all kinds of sense to install into a named subdir. But with method (a) above -- $cwd -- the end user can control that herself by creating the working tree before calling mingw-get source. Really, (a) seems like the best bet -- AND doesn't impose some arbitrary standard on package suppliers. I'd really hate that. I've already (in 2009) gone thru the (mind numbing) process of rebuilding the entire msys and mingw package set TWICE simply to adhere to a new, imposed, "standard". Those two times were in order to obey the new, in flux, package naming scheme. Since that effort was required in order for mingw-get to work, it was...acceptable. I see NO reason to go thru that effort for mere COSMETIC distaste. > I've tended not to like Chuck's style of source deliver either. I would > rather see the patched source be delivered in the -src file and if need > be the configure/build options given in the README file. Frack that. Sure, it makes rebuilding THE SAME VERSION of $foo easy(ish) -- you still have to manually create the build dir, (or, if README says $foo isn't VPATH-compatible, create a shadow dir or build in src). Do configure manually, according to the readme -- if it is autoconfed. Do the build -- with the right envvar settings, if necessary. Check the README. Do the install -- with the right arguments: does it support DESTDIR? Will it recognize a new prefix=? Maybe it uses some obscure variable like INSTALLROOT. Check the README. Then, if you've modified the source, you need to clean it up because you don't want to package .o's -- if you build in the source dir. Plus, you may have needed to run autoreconf anyway, because you added support for msys or libtool-$new, and that always mucks with the source dir, VPATH or no. So, clean that up too. Now you're ready to package the source. But suppose Bob did this for foo-$VER, and now I want to update to foo-$NEW. Well, first I download his foo-$VER-src package, and I have to figure out what in the hell he changed. So, I also d/l the pristine foo-$VER.tar.gz and unpack that. I generate a diff -- and now I've got: 1) a ton of autoconf, automake, and possibly libtoolize and gettextize derived changes, scattered over 50 files. 2) a bunch of packaging changes (e.g. the MSYS release notes, maybe some msys-custom helper scripts, etc) 3) all of the source changes jumbled together. If, for instance, Bob adopted three patches from gentoo, AND applied his own changes...they're all mixed together. I can't forward port them in easy-to-manage chunks. It's all or nothing. It's not THAT much easier for Bob himself to update the package to foo-$NEW, either. I don't want to be Bob. There are about 60 different msys packages. Each has its quirks. Bob would quickly go mad trying to manage this the Earnie-approved(tm) way. Which goes a long way toward explaining why this: http://mingw.cvs.sourceforge.net/viewvc/mingw/msys/packages/ contains a bunch of WRITE-ONLY ports, that were created 10 years ago and never updated until I did it in 2009. (Trust me, teasing out all the changes, and forward porting them to versions seven or eight years newer, was decidedly non-trivial, thanks to the Bob source management "system"). The Bob way makes it too damn hard to upgrade a given package, and forward port its changes, to the next upstream release. > I've lived > with the delivery method because I know how to patch but I've found it > inconvenient. Hell, Earnie, you don't even need to know how to do that. That's what the fracking build script is for. And newer packages use Cesar's msysrlsbld framework, which is even easier. The drawback is, neither the current msysrlsbld framework, nor my older msys-build-$foo scripts, nor mingwPORT, support cross compiling from linux. And I suspect that is the real objection here (which raises an obvious question, but I'll defer that; it's even more inflammatory than the current rant). I hope, one day, to finish my port of current cygport to msys (msysport?). With its cross-compiling support, we may then be able to enable cross builds of msys packages (given a linux->msys toolchain, which is probably a prereq anyway for initial development work on msys-2.0). A similar, but necessarily separate (long story), port of cygport to support mingw (mingwport? nope, already taken. mport?) would also help on the mingw side of things, but that's an even longer term effort, even though there already exist linux->mingw toolchains). As you can see, I feel pretty strongly about this -- because I've already DONE it the way you guys seem to prefer. It might be managable if all you care about is a single package or two -- but scale up to 60 or 100 source packages -- or 2000, as Yaakov [creator of cygport] supports on cygwin -- and you end up with stale packages that aren't updated for years and years. And that's what we saw with all of the MSYS tools back with the source was "managed" using the "just save the modified source as-is (either in a CVS repo, or bundled in a tarball)" system. I am NOT inclined to waste my time repackaging source to fit someone else's mere preferences -- unless they want to completely take over management of the affected package and I'll wash my hands of it. There's no reason to impose any such requirements on -src packages, and frankly mingw-get's source action can unpack them however Keith likes. I'll deal. But I'm not going to do extra work for cosmetics -- especially as beauty is in the eye of the beholder, and when I behold the Earnie style -- my first thought is, My God, Ugly Goes All The Way To The Bone. -- Chuck |
From: Keith M. <kei...@us...> - 2011-08-12 21:29:51
|
On 12/08/11 18:26, Charles Wilson wrote: > Long History And [irate] Rant [...snipped...] Calm down, Chuck; there's no need to throw your toys out of the pram. I can tell that you feel passionately about this, but let's try to establish some sense of perspective; I've expressed a dislike for a source package structure such as: foo-1.0-mingw32-src.tar.xyz buildscript patchfiles foo-1.0-src.tar You've responded with a vitriolic diatribe, claiming that any alternative would be unworkable, yet within that diatribe, I'm not seeing any compelling argument to convince me of that. On the contrary, if you really mean that every package delivers a script file called "buildscript", then you are already violating your own principle that any single file, (in a single specific path), should be delivered by only one package; here you have *every* package delivering a file called "buildscript", (and they are likely conflicting copies), into a (potentially) common ${abs_top_srcdir}. Perhaps similarly for your patchfiles; might there also be conflicts amongst them? Now, if what you really mean is: foo-1.0-mingw32-src.tar.xyz foo-1.0-buildscript foo-1.0-patchfiles/ foo-1.0-src.tar then okay, those potential conflicts don't arise, and my objection boils down, primarily, to the concept of embedding one tarball within another; it is grossly ugly, and frankly, utterly unnecessary. I fail to comprehend how making me untar it twice is better than: foo-1.0-mingw32-src.tar.xyz foo-1.0-buildscript foo-1.0-patchfiles/ foo-1.0/ content of foo-1.0-src.tar unpacked... which would seem to deliver what you want, while only requiring me to untar once, to get to a fully populated source tree. Note that, unlike Earnie's apparent preference, I'm not demanding that the unpacked content of foo-1.0/ should already have the patch files applied. Frankly, I couldn't care less either way; provided I have the full set of patches, I can transform it in either direction, by applying forward or reverse patches, as appropriate. Now, I might argue in favour of moving the buildscript and patchfiles; something along the lines of: foo-1.0-mingw32-src.tar.xyz foo-1.0/ arch/ mingw32/ buildscript patchfiles... content of foo-1.0-src.tar unpacked... It's tider, (encapsulates the package better), and frankly, I think your argument against it is grossly overstated. However, that's not something I want to make an issue of; I can live with it either way. Finally, with regard to "biting the bullet", I am *not* asking you to spend hundreds of hours repackaging everything; I'm not asking *you* to repackage anything. Firstly, it is only the source packages which need to be touched, and secondly, I meant that we could collectively tackle the reorganisation; if no one else steps forward to help with it, I perfectly willing to tackle it myself, as and when I can spare some time -- it isn't an especially urgent requirement. -- Regards, Keith. |
From: Earnie <ea...@us...> - 2011-08-13 18:51:40
|
Keith Marshall wrote: --8<-- > foo-1.0-mingw32-src.tar.xyz > foo-1.0-buildscript > foo-1.0-patchfiles/ > foo-1.0/ > content of foo-1.0-src.tar unpacked... > > which would seem to deliver what you want, while only requiring me to > untar once, to get to a fully populated source tree. > > Note that, unlike Earnie's apparent preference, I'm not demanding that > the unpacked content of foo-1.0/ should already have the patch files > applied. Frankly, I couldn't care less either way; provided I have the > full set of patches, I can transform it in either direction, by applying > forward or reverse patches, as appropriate. > My dislike is more the fact that I have to do the tar twice and yes, patching forward or reverse is fine with me. > Now, I might argue in favour of moving the buildscript and patchfiles; > something along the lines of: > > foo-1.0-mingw32-src.tar.xyz > foo-1.0/ > arch/ > mingw32/ > buildscript > patchfiles... > content of foo-1.0-src.tar unpacked... > > It's tider, (encapsulates the package better), and frankly, I think your > argument against it is grossly overstated. However, that's not > something I want to make an issue of; I can live with it either way. > I agree with this. > Finally, with regard to "biting the bullet", I am *not* asking you to > spend hundreds of hours repackaging everything; I'm not asking *you* to > repackage anything. Firstly, it is only the source packages which need > to be touched, and secondly, I meant that we could collectively tackle > the reorganisation; if no one else steps forward to help with it, I > perfectly willing to tackle it myself, as and when I can spare some time > -- it isn't an especially urgent requirement. > Ditto. There is no need to repackage existing packages. But applying to semantics going forward. Earnie |
From: Charles W. <cwi...@us...> - 2011-08-25 20:07:07
|
On 8/12/2011 5:29 PM, Keith Marshall wrote: > On 12/08/11 18:26, Charles Wilson wrote: > You've responded with a vitriolic diatribe, claiming that any > alternative would be unworkable, No, I never said unworkable -- sure, it's DOable, .deb packages do it all the time (although they are structured as *ar* archives -- that is, uncompressed -- containing the original tarball and the debian customization overlays, including patches-which-create-patches that are then applied... Now THAT's ugly -- but workable. (Besides, they provide automation tools). I said your scheme was awkward and difficult to deal with, without automation tools. (Specifically, I said it was a fracking PITA). I provided a history of the experience of a couple dozen package maintainers on cygwin, over the course of a decade, showing the evolution of THEIR packaging scheme /from/ the sort of scheme you and Earnie prefer, /to/ something more akin to SRPMS. Given a free choice, with zero pressure, the migration percentage away from debian-style (cygwin method one, similar to mingwPORT) to cygwin g-b-s (akin to msys-build-foo) to cygport (similar to msysrlsbld, and the upcoming [mgw|msys]port) was better than 90% and probably closer to 99%, with the holdouts being those (cgf, Jan N.) who developed their own independent build system. That says something about the relative ease of use -- for maintainers -- of the various schemes. I also expressed my frustration with the debian-like structure created by mingwPORTs (where the src tarball is unpacked "around" the customization/porting scripts..."tidier"? Not hardly). There's no (current) automated mechanism for updating customized local copies of those scripts, when the upstream mingwPORT/ is improved; nor is there (currently) any automated mechanisms for forward-porting patches to the target source code, when updating to a new release of $foo. And, having patches buried deep inside the source tree that you're trying to diff is ugly; diff -urN -x mingwPORT/ ... but that's merely cosmetic. Also, mingwPORT's own "unapply all patches after building" interferes with the ability to automate such patch generation. There's no way to single-step the build process (e.g. "just do configure" or "I've already built; just do install" or "do everything BUT unapply any existing patches; I've edited some source and need to regenerate the patch...using an -orig directory I've manually created elsewhere) short of editing mingwPORT.sh... Since all of my current *mingw* packages are packaged like this: -src.tar.bz2 orig-tarball mingwPORT-like tarball other than the two extra untar steps, it's the REST of the operation that annoys me. Typing tar -xvf twice takes seconds; updating the mingwPORT scripts properly takes hours, depending on how much upstream mingwPORT CVS has changed -- granted, not much in recent years. OTOH, with cygwin's cygport scheme -- or Cesar's msysrlsbuild scheme -- I inherit upstream cygport improvements instantly, and forward-porting the src patchset to version x.y.z+1, and regenerating the new patch, is not made any more difficult by the packaging format. I think it is somewhat foolish to ignore the experience of others. > yet within that diatribe, I'm not > seeing any compelling argument to convince me of that. On the contrary, > if you really mean that every package delivers a script file called > "buildscript", then you are already violating your own principle that > any single file, (in a single specific path), should be delivered by > only one package; here you have *every* package delivering a file called > "buildscript", (and they are likely conflicting copies), into a > (potentially) common ${abs_top_srcdir}. Perhaps similarly for your > patchfiles; might there also be conflicts amongst them? Well, originally no -- recall my mingw packages were really just mingwPORT tarballs + the upstream src tarball, pre-"downloaded" to satisfy the GPL. I packaged them this way because a) I thought mingwPORT was the "official" scheme, so I wanted to stick with it -- no matter how distasteful I personally found it to be. b) The only way to convince mingwPORT.sh to skip the download step was to make sure the original tarball already exists at the location it expects. This argued against consolidations a la' foo-1.2.3/ <original source code, unpacked> mingwPORT/ <mingwPORT scripts and patches, unpacked> because the mingwPORT script expects to do the unpacking, itself. So, it made since to provide either foo-1.2.3-N-src.tar foo-1.2.3.tar.bz2 (upstream) foo-1.2.3/ <empty, except for> mingwPORT/ <mingwPORT scripts and patches, unpacked> OR foo-1.2.3-N-src.tar foo-1.2.3.tar.bz2 (upstream) foo-1.2.3-N-mingwPORT.tar.bz2 foo-1.2.3/ mingwPORT/ <mingwPORT scripts & patches> I opted for the latter...since I figured -mingwPORT.tar.bz2 files were already "familiar". Anyway, this scheme has no "clashes" -- except that the mingwPORT/*.sh binary packaging portion might make some assumptions about ownership of foo-1.2.3/mingwPORT/../../ -- it might put the <tmp_inst>/ directory up there (which would clash)... OTOH, my msys packages were all foo-1.2.3-N-msys-src.tar.bz2 foo-1.2.3.tar.bz2 (upstream) $buildscript: msys-foo-build $patch: foo-1.2.3-msys.patch In general, there should not be any clash within a common $top_src_dir, with packages of this type. However, recently I've been adopting Cesar's msysrlsbld script instead, and THAT does create files with possibly clashing names, if unpacked into the same $top_src_dir: msysrlsbld msysrlsbld.ini > my objection boils > down, primarily, to the concept of embedding one tarball within another; > it is grossly ugly, and frankly, utterly unnecessary. I fail > to comprehend how making me untar it twice is better than: > > foo-1.0-mingw32-src.tar.xyz > foo-1.0-buildscript > foo-1.0-patchfiles/ > foo-1.0/ > content of foo-1.0-src.tar unpacked... > > which would seem to deliver what you want, while only requiring me to > untar once, to get to a fully populated source tree. Because it makes it VERY difficult for me to prepare that foo-1.0 directory, AFTER I have built the package, in order to regenerate the -src tarball. Suppose the build script does this: a) apply patchfiles/fixup-configure-ac-and-Makefile-am.patch b) apply patchfiles/fixup-src.patch c) autoreconf Now, how exactly do I undo that, to return to a pristine foo-1.0/ that can be packaged up? (Remember, I don't have the tarball anywhere) Sure, I can use patch -R for the patchfiles, but I'd find it very difficult to "undo" the autoreconf. I'd really rather not ship 400K worth of patches, just so that the buildscript could do this instead: a) apply patchfiles/fixup-configure-ac-and-Makefile-am.patch b) apply patchfiles/fixup-src.patch c) apply patchfiles/pretend-to-autoreconf.patch so that patch -R can do all the work. Furthermore, if I need to actually edit some of the source code, how do I (re)generate a new fixup-src.patch? Well, my build script will have to make a copy of foo-1.2.3/ before I do *anything*, just so I still have it around later (remember, I can't just "unpack the pristine tarball" because I don't have it). Then, I need to do the directory dance: diff -urN -x (various autoconf regens) foo-1.2.3-save/ foo-1.2.3/ mv foo-1.2.3 foo-1.2.3-used-this-one-to-build mv foo-1.2.3-save foo-1.2.3 <make -src tarball> But now, I need to undo that directory dance, if I want to be able to go back and fix something /else/ and rebuild... Alternatively, I can just carry around the original src tarball, and unpack it, in as many multiple places as necessary, to do what I need. I don't really see the difference between 1) 1 toplevel package untar, plus N additonal pristine source untar 2) 1 toplevel package & pristine source untar + (N-1) 'cp -dpr' Sure, there are other ways to handle this -- but it all requires me to do something, manually. I'd really rather be able to automate. > Finally, with regard to "biting the bullet", I am *not* asking you to > spend hundreds of hours repackaging everything; I'm not asking *you* to > repackage anything. Firstly, it is only the source packages which need > to be touched, Not so -- if I didn't build foo using /this exact foo-src package/ following /exactly the documented procedure/, then IMO I haven't complied with the GPL -- in spirit, at least. So, "fixing" the -src package means regenerating the -bin|-dev|etc packages that go along with it. And that means bumping the release number, and updating the manifest(s)... > and secondly, I meant that we could collectively tackle > the reorganisation; if no one else steps forward to help with it, I > perfectly willing to tackle it myself, as and when I can spare some time > -- it isn't an especially urgent requirement. Far from being "urgent" I think it is an utterly useless "requirement" -- in fact, counterproductive, as the activity would divert valuable developer time from useful tasks like getting msys-git ported, or msys-tcl, or improving mingw-get -- and not worth even the time spent so far discussing the possibility. There is simply *no issue*: go ahead and have mingw-get unpack src wherever you like (cwd, /usr/src|/mingw/src), with or without the "extra" level of directory. I don't care -- if you don't do it my preferred way, I'll deal with it. I'd rather address the meta issue of tools to automate package creation and maintenance. To judge by mingw32-zlib and mingw32-bzip2, Keith believes that 'make' has all the expressive power he would ever need, so everything can be handled by directly patching the build infrastructure of package $foo directly -- and maybe for a 'make' guru like Keith that is true. It's not true for me -- yee gods, but mingw-get's own makefiles make my eyes bleed... So... I've almost finished porting/rewriting cygport as mgwport along with its own build-prereqs (msys-help2man) and runtime prereqs (msys-rsync, msys-diffutils); it can currently self-host the mgwport package itself on mingw, as well as cross-host itself from cygwin. The only remaining tweaks are (1) to customize the automatic naming scheme: cygport subpackages all have distinct initial names like tiff tiff-doc tiff-opengl libtiff-devel libtiff6 whereas mgwport subpackages sometimes have identical initial names and differ in component-type. So, the above example would need to be named as: tiff-*-bin tiff-*-doc tiff-opengl-*-bin libtiff-*-devel libtiff-*-dll-6 and the mgwport code needs some modification to handle the "split" between package name and component type. (2) to handle the omission of the top-level directory when packaging mingw: <inst>/mingw/bin/foo <inst>/mingw/lib/libfoo <inst>/mingw/etc/foo.rc <inst>/mingw/var/run/foo/data needs to be packaged from the /mingw/ dir, so that the archive(s) contain bin/foo lib/libfoo etc/foo.rc var/run/foo/data Similarly, msys temporary installation directories need to be *reorganized* (or the tmp installation has to be controlled differently than it currently is, being cygport-derived code) before creating the packages: <inst>/usr/bin/foo <inst>/usr/lib/libfoo <inst>/etc/foo.rc <<< /etc at same level as /usr <inst>/var/run/foo/data <<< ditto /var so that the package tarballs contain bin/foo lib/libfoo etc/foo.rc var/run/foo/data (3) Testing to make sure it can be used with a msys-target or mingw-target cross compiler on $other-build (like linux), and still create identical packages to ones generated "natively". Especially wrt to sysroot issues and lib dependencies. (cygport-0.10.4 can do so for cygwin, when using a linux->cygwin cross compiler, with an added step of running the included "sysrootize" script; the only question is have I broken anything?) Anyway, at first the -src packages generated by mgwport will look like cygport ones: foo-1.2.3.tar.bz2 foo-1.2.3-1.mgwport foo-1.2.3-1.src.patch << deltas to src files foo-1.2.3-1.mgw.patch << deltas "creating" files in foo-1.2.3/MINGW-PATCHES/ (*) because that keeps the fork from cygport smaller. (*) like maybe the "original" mingw-foo.xml manifest, or the .RELEASE_NOTES. Or optionally .list files to specify which files go in which subpackage -- normally this is handled by tar expressions in the .mgwport (see below) but sometimes explicit lists are easier (erm, gettext...). Small tweaks like putting things in a subdir: foo-1.2.3-1/ foo-1.2.3.tar.bz2 foo-1.2.3-1.mgwport foo-1.2.3-1.src.patch foo-1.2.3-1.mgw.patch are easy, larger changes like doing this: foo-1.2.3-1 foo-1.2.3/<unpacked upstream src files> foo-1.2.3-1.mgwport foo-1.2.3-1.src.patch foo-1.2.3-1.mgw.patch and using 'cp -dpr' (actually, rsync) to create the "working src" dir(s) instead of tar -x, are /somewhat/ more difficult since so much in cygport is based on a variable called "SRC_URI" which represents /where/ the source comes from...it can be a URI of a tarball, but in some cases it can be a local tarball, which can be created from a 'cvs export' or a 'git clone' command -- e.g. SRC_URI=xz-5.0.2_20110517.tar.gz # no http:// path in this case # snapshot from Tue May 17 12:26:28 2011 +0300 GIT_MODULE=xz GIT_URI=git://ctrl.tukaani.org/xz.git GIT_REV=841dc1f891b48b23f84c0f0e0c86c7c4e4bdcdf5 inherit git enables the following command: mgwport <package>.mgwport download to clone the upstream repo, roll it back to the specified revision, remove the .git debris, and create a .tarball of the result. Since we (have to) ship sources, this is less useful downstream -- but is quite helpful for the maintainer himself. The "simplest" (3 subpackages: -bin, -doc, -lic, + -src) .mgwport would probably look something like this: ===================== mgwport-0.10.4-1.mgwport ============ DESCRIPTION="Next-generation MinGW/MSYS packaging application" HOMEPAGE="http://sourceware.org/cygwinports/" # ok, that's wrong SRC_URI="mirror://sourceforge/cygwin-ports/${P}.tar.bz2" # this too # PN, PV, and PR are automatically detected by parsing the # input scripts' name. In this case, PN=mgwport, PV=0.10.4, # and PR=1. Subsystem is automatically detected based on whether the # script extension is ".mgwport" or ".msysport" -- but can be overridden # in the script itself. I think additional versioning would not be # automatically parsed; instead the .mgwport script would # explicitly set PRELSTATUS=alpha, PRELREF=20110723-2, etc. if # desired. PKG_NAMES="${PN} ${PN} ${PN}" PKG_COMPTYPES="bin doc lic" PKG_CONTENTS[0]='bin/*.exe lib/ share/mgwport/ etc/' PKG_CONTENTS[1]="--exclude=share/doc/${PN}/${PV}/COPYING share/doc share/man share/info" PKG_CONTENTS[2]="share/doc/${PN}/${PV}/COPYING" # We use the standard src_compile, src_test, and src_install # but those functions could be overridden here. ===================================================== So you'd do: mgwport mgwport-0.10.4-1.mgwport all or individual steps mgwport mgwport-0.10.4-1.mgwport prep mgwport mgwport-0.10.4-1.mgwport conf mgwport mgwport-0.10.4-1.mgwport build mgwport mgwport-0.10.4-1.mgwport check mgwport mgwport-0.10.4-1.mgwport install mgwport mgwport-0.10.4-1.mgwport pkg mgwport mgwport-0.10.4-1.mgwport finish (aka cleanup) to create mgwport-0.10.4-1-mingw32-bin.tar.lzma mgwport-0.10.4-1-mingw32-doc.tar.lzma mgwport-0.10.4-1-mingw32-lic.tar.lzma mgwport-0.10.4-1-mingw32-src.tar.lzma I should have a proof of concept sometime in the next week, with sample .mgwport and .msysport for a few packages -- say, zlib and xz -- tested and hopefully working on "native" mingw and msys, as well as linux->mingw cross (with NO changes to the .mgwport itself). I'll upload the prereqs tonight: msys-rsync, msys-help2man, and msys-diffutils. -- Chuck |
From: Keith M. <kei...@us...> - 2011-08-26 20:16:23
|
With respect, I'm getting bored with this rant. On 25/08/11 21:07, Charles Wilson wrote: >> ... I fail to comprehend how making me untar it twice is better >> than: >> >> foo-1.0-mingw32-src.tar.xyz >> foo-1.0-buildscript >> foo-1.0-patchfiles/ >> foo-1.0/ >> content of foo-1.0-src.tar unpacked... >> >> which would seem to deliver what you want, while only requiring me to >> untar once, to get to a fully populated source tree. > > Because it makes it VERY difficult for me to prepare that foo-1.0 > directory, AFTER I have built the package, in order to regenerate the > -src tarball. Poppycock. Given the structure I would ultimately prefer: foo-1.0-mingw32-src.tar.xyz foo-1.0/ original content of foo-1.0-src.tar unpacked ... arch/ mingw32/ build-script.sh foo-1.0-mingw32.patch I would do something like: $ wget -O foo-1.0-src.tar.xyz http://foo-home.org/foo-1.0-src.tar.xyz $ tar xf foo-1.0-src.tar.xyz $ cd foo-1.0 $ cat <<EOF> .hgignore syntax: glob .hgignore **.patch staged/ EOF $ hg init $ hg branch origin $ hg add . $ hg ci -m 'Initial import of upstream foo-1.0-src' $ hg branch mingw32 $ mkdir -p arch/mingw32 Now, create arch/mingw32/build-script.sh, do whatever else you need to get to a viable mingw32 build, enumerate whatever other build artefacts you want to exclude from your source tarball in .hgignore, and then: $ hg add . $ hg ci -m 'As built foo-1.0-mingw32-src' $ mkdir -p staged $ hg clone -b origin . staged/foo-1.0-mingw32 $ mkdir -p staged/foo-1.0-mingw32/arch/mingw32 $ cp arch/mingw32/build-script.sh staged/foo-1.0-mingw32/arch/mingw32 $ hg diff -r origin -X arch/mingw32/build-script.sh \ > staged/foo-1.0-mingw32/arch/mingw32/foo-1.0-mingw32.patch $ rm -rf staged/foo-1.0-mingw32/.hg $ cd staged $ tar cf foo-1.0-mingw32-src.tar foo-1.0-mingw32 all of which, except for the non-specific actions in the middle, lends itself readily to two-stage automation, yielding a source tarball which comprises unadulterated upstream source, plus a patch file to convert it to mingw32-ready source, and the mingw32 specific build script, both neatly encapsulated within the arch/mingw32 subdirectory. What's wrong with that? You've got everything you need to distribute, and no need for your "patches to update patches" difficulty. > Furthermore, if I need to actually edit some of the source code, how do > I (re)generate a new fixup-src.patch? Well, my build script will have to > make a copy of > foo-1.2.3/ > before I do *anything*, just so I still have it around later (remember, > I can't just "unpack the pristine tarball" because I don't have it). Huh? You're embedding the frigging thing in your distributed package; how can you NOT have it? Using an hg based strategy, (or equivalent using your favourite CMS), such as I outline above, you've captured it at the outset, on the "origin" branch, so: $ hg clone -b origin . staged/foo-1.0 $ rm -rf staged/foo-1.0/.hg will reconstruct it, in unpacked form, at any time. Sorry, I just don't buy your argument. > There is simply *no issue*: go ahead and have mingw-get unpack src > wherever you like (cwd, /usr/src|/mingw/src), with or without the > "extra" level of directory. I don't care -- if you don't do it my > preferred way, I'll deal with it. Okay. I'm going to implement mingw-get such that it will: - download source tarballs to $APPROOT/var/cache/mingw-get/source - unpack ONE tarball level, placing the resultant tree in $PWD If you can adapt to that, fine. If it means there's one extra level of tarball to unpack manually, that's a minor (unnecessary) inconvenience, (infringing your automation goal). If it results in source packages trampling over one and other, when they're "mingw-get source"d into a common $PWD, then that's hardly acceptable, (unless YOU are prepared to "deal with it" on behalf of all end users). -- Regards, Keith. |
From: Keith M. <kei...@us...> - 2011-08-26 21:14:52
|
On 26/08/11 21:16, Keith Marshall wrote: [FTR: recreating original source archive] > $ hg clone -b origin . staged/foo-1.0 > $ rm -rf staged/foo-1.0/.hg > > will reconstruct it, in unpacked form, at any time. In fact, mercurial does have an equivalent for "cvs export", which I overlooked initially: $ hg archive -r origin -X '.hg*' staged/foo-1.0 will do it in one. -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2011-08-26 21:19:16
|
On 8/26/2011 4:16 PM, Keith Marshall wrote: > With respect, I'm getting bored with this rant. Me too. > What's wrong with that? You've got everything you need to distribute, > and no need for your "patches to update patches" difficulty. Because it requires the end "user" -- actually, a dev who wants to rebuild from one of our -src packages -- to create a local CMS repo in order to repeat my build action. With CVS (or svn), that's definitely overkill, since CVS can't init a repo in place -- and frankly, 'cvs init' is basically 'cp -dpr' with some additional overhead. For "in place" CMS, like git (hg?) that's a reasonable idea -- except that we don't currently include either in our base package set (or at all, actually). >> before I do *anything*, just so I still have it around later (remember, >> I can't just "unpack the pristine tarball" because I don't have it). > > Huh? You're embedding the frigging thing in your distributed package; > how can you NOT have it? No, I'm saying that if I only ship *unpacked* source, as you recommend, then after I have patched/re-autoconfed it I do NOT have the original upstream tarball/unpacked source. Now, sure, it still exists inside *our* tarball, so something like this: tar -C origsrc/ -xvf foo-1.2.3-1-mingw-src.tar.lzma foo-1.2.3/ would work for rebuilding exactly foo-1.2.3-1. But...bootstrapping that gets tricky, since if I start from scratch for foo-1.2.4 I don't yet HAVE the -mingw-src.tar.lzma... So, if we assume that the -mingw-src.tar.lzma is unavailable (e.g. a brand new port or version bump), then we could make the assumption the upstream tarball IS available in that particular case. But that means the automation script has to have some odd logic in it, to figure out which tarball to get the src FROM, when it needs to do create the .patch. OR, the automation could take some action, prior to applying any patches or autoreconf'ing, to preserve the original pristine unpacked source *directory*, regardless of its origin. Whether that's to 'cp -dpr' to somewhere else, or to init a new local CMS repo with the pristine unpacked data. As the only official msys CMS tool we currently ship is cvs, and initing a new cvs repo is not as trivial as it may be with other CMS, I advocate, at least for the present, to preserving the "pristine source" in some other directory. So...then it boils down to 'cp -dpr' vs. a second untar (and the latter requires to ship the original tarball, rather than unpacked source). > Sorry, I just don't buy your argument. I know we talked about whether it'd be acceptable to require a specific CMS tool that we don't actually provide, in order to access the MinGW/MSYS repo on sourceforge. But that's a different topic than whether its kosher to embed assumptions about hg or git [cvs? boo!] availability in the every single build script we ship. I don't think that would be a good idea. ("Sure, you can download the -src to msys-foo; we'll even unpack it and provide a build script for you. But you can't actually use the build script unless you install ActiveState python from http://over/there, and Mercurial from http://this/other/place...") Maybe after I finish the whole git thing, we could revisit this, and I could revise mgwport since git allows in-place CMS. hg might, as well, but then it "suffers" from the not-from-mingw.org issue (and quite honestly, I have no desire to try to port python to msys). >> I'll deal with it. > > Okay. I'm going to implement mingw-get such that it will: > > - download source tarballs to $APPROOT/var/cache/mingw-get/source > - unpack ONE tarball level, placing the resultant tree in $PWD > > If you can adapt to that, fine. Perfect. <not a complaint>It may cause some issues with -src packages that use Cesar's msysrlsbld/pkgbuild scripts, but we can address those by modifying those packages on as as-needed, normal-course-of-development basis. There aren't many of them.</not a complaint> > If it means there's one extra level of > tarball to unpack manually, that's a minor (unnecessary) inconvenience, > (infringing your automation goal). If it results in source packages > trampling over one and other, when they're "mingw-get source"d into a > common $PWD, then that's hardly acceptable, (unless YOU are prepared to > "deal with it" on behalf of all end users). I've finished almost all of the porting work for mgwport (works in both mingw and msys flavors). IOW, I've completed tasks #1 and #2 from previous email. I just need to (a) develop some proof of concept ports for, e.g. zlib ('cause it's simple), xz ('cause it has DLLs, EXEs, and scripts), and perhaps gettext (*) in both mingw and msys, and (b) verify they allow to build from linux->mingw build environments (task #3 from previous email). We don't have a linux->msys build environment, so that's a non-issue for now. To prevent any possibility of collision, I'll go ahead and make this simple change to the -src packages mgwport creates (task #4): foo-1.2.3-1[-subsys[-subsysver]][-status[-statusversion]-src/ foo-1.2.3.tar.bz2 foo-1.2.3-1.mgwport | .msysport foo-1.2.3-1.src.patch foo-1.2.3-1.mgw.patch | .msys.patch (*) gettext because (a) it'd be really good to update beyond 0.17, and (b) it gives mgwport a real workout, using some facilities that simpler packages don't exercise. There's another reason for concentrating on gettext and libintl, having to do with their internal 'relocatable' support...I have an old *cyg*port patch that adds the ability to deal with that, and I need to port it to mgwport. So that's a new task #5. -- Chuck |
From: Keith M. <kei...@us...> - 2011-08-27 12:48:33
|
On 26/08/11 22:19, Charles Wilson wrote: >> What's wrong with that? You've got everything you need to >> distribute, and no need for your "patches to update patches" >> difficulty. > > Because it requires the end "user" -- actually, a dev who wants to > rebuild from one of our -src packages -- to create a local CMS repo in > order to repeat my build action. No, it doesn't. Chuck, I "hear" what you are saying, but I am still not buying your argument. You start at "A": an unadulterated upstream source tarball. From that you figure out what is required to transform that, to get to point "B": another source tarball which is suitable for building a mingw32 variant of the application. Assume you've adopted the technique I proposed; you've provided a copy of the original tarball, augmented by a build script and a patch set, in a supplementary subdirectory. Joe Enduser takes your point "B" source tarball, from which he wants to compile the application. With that, he can immediately follow the build method of the upstream project, to build for any platform which is supported OOTB, or he can run your arch/mingw32/mingw32-build.sh to build for mingw32, (which by inference, would not have worked OOTB). In the former case, the additional files you've added are irrelevant; they don't participate in the build process, which proceeds just as if Joe had used the original point "A" tarball from upstream. In the latter case, your final point "B" patch set is applied, and provided Joe has taken care that any build dependencies you've stipulated are satisfied, he ends up with a mingw32 build of the application. Does Joe care what path you followed to get from "A" to "B"? Not at all; it is completely irrelevant to him. All he cares about is that he can use your source tarball to achieve a successful build, on whichever platform is of interest to him. (That it works for any platform which is supported by the upstream project is a bonus, about which he may or may not care; he probably chose your tarball, in the first instance, because his primary interest lay in the mingw32 build capability). Okay. Joe Enduser doesn't care a fig how you got from "A" to "B", but what about Sue Hacker? She may be taking up the maintenance of your patched package. Does she care how you got from "A" to "B"? She certainly has more reason than Joe to be interested, but of much more interest to her than the "how", is the "why". You may have gone six times around the solar system, via Uranus, and she can achieve the same result with a quick hop to Venus and back. Is Sue's path any less valid than yours? No, it is not. The actual path she has followed is irrelevant, provided the end result is the same. Sue needs to understand *why* you made the changes you did, not *how* you made them, and the information she needs should be encapsulated in the extra files you've added to the original package, in the form of comments or other documentation. There is absolutely no need for Sue to faithfully reproduce every step you took, using identically the same tools; provided she understands why you went from "A" to "B", any alternative path she may choose, which leads to the same destination, is equally satisfactory. You are over-thinking the issue, adding one plus one, and arriving at an answer of six. -- Regards, Keith. |
From: Earnie <ea...@us...> - 2011-08-29 13:05:34
|
Charles Wilson wrote: > On 8/26/2011 4:16 PM, Keith Marshall wrote: >> With respect, I'm getting bored with this rant. > > Me too. > >> What's wrong with that? You've got everything you need to distribute, >> and no need for your "patches to update patches" difficulty. > > Because it requires the end "user" -- actually, a dev who wants to > rebuild from one of our -src packages -- to create a local CMS repo in > order to repeat my build action. With CVS (or svn), that's definitely > overkill, since CVS can't init a repo in place -- and frankly, 'cvs > init' is basically 'cp -dpr' with some additional overhead. For "in > place" CMS, like git (hg?) that's a reasonable idea -- except that we > don't currently include either in our base package set (or at all, > actually). > Well, hardly. A casual user of the source only wants to configure, make and make install. Some developer taking over maintenance of a package or even one just interested in improving a MinGW package will setup a repository of his liking from the upstream repo and reproduce the patch from our provided source so that he can try to keep up with the upstream patching. The ratio of casual user to developer user is slanted to the casual user by a wide margin. So my preference for the source to already contain the patch is due to the slant toward the casual user. But your source packages do contain a script that can be used to automate the process for the casual user; but your script causes the casual user to never learn the simple basics of configure and make. Both of our methods satisfy the GPL and the GNU package standards but affect the end user differently. I don't disagree 100% with your rantings of my style, I don't agree 100% either. My methods served the MinGW community just as your methods do now. We are all different and have differing styles of producing work. The one thing some are able to cope with more than others is adapting style with changing methods especially when it is troublesome to the soul. Keith's method, your method, my method or someone else's method, in the end the method that wins becomes what is good for mingw-get and that will tend to be the one that is coding mingw-get; but I know Keith is open minded to reason if someone's reason can be shown to be of more benefit to the casual user. It is the casual user that any method must benefit since a developer will choose his own methods. Earnie |
From: Keith M. <kei...@us...> - 2011-10-08 09:42:51
|
On 26/08/11 22:19, Charles Wilson wrote: >> Okay. I'm going to implement mingw-get such that it will: >> >> - download source tarballs to $APPROOT/var/cache/mingw-get/source >> - unpack ONE tarball level, placing the resultant tree in $PWD >> >> If you can adapt to that, fine. > > Perfect. <not a complaint>It may cause some issues with -src > packages that use Cesar's msysrlsbld/pkgbuild scripts, but we can > address those by modifying those packages on as as-needed, > normal-course-of-development basis. There aren't many of them. > </not a complaint> Okay. I've now committed a tentative implementation of this to CVS; it implements both 'mingw-get source ...' and 'mingw-get licence ...' requests, (but not yet any "build-requires" capability). Both of these new requests operate as described above, (except that "licence" will shepherd downloaded "-lic" tarballs into the normal package cache directory, $APPROOT/var/cache/mingw-get/packages); in both cases, the downloaded tarball will be unpacked in $PWD, with nothing being "installed" in the associated $SYSROOT directories. As with the "install" request, you may use the "--print-uris" option to suppress downloading and "installing" (i.e. unpacking), while reporting the URI whence the package would be downloaded; alternatively, you may use the "--download-only" option to achieve the download, (into the appropriate cache directory), while suppressing installation/unpacking. (Note that both of these options now imply "--reinstall", to ensure that the request is honoured, regardless of the installation status of the associated binary package). In addition to the preceding two options, you may also use the new "--all-related" option, to apply the request recursively, processing the source/licence tarballs for all auxiliary packages which are needed to satisfy the runtime requirements of the associated binary package, in addition to those of the package specified on the command line. I'm reluctant to roll out an immediate release, because my own testing has revealed a weakness in our mingw-dist manifests; specifically: <source tarname="foo-%-msys-%-src.tar" /> is not sufficiently deterministic to identify the name of the source tarball -- the compression type is indeterminate. Likewise for: <licence tarname="foo-%-msys-%-lic.tar" /> I think we should fix this, before progressing a roll out. I don't like the idea of an heuristic bodge, to guess a missing compression type, so we may either include it explicitly, e.g.: <source tarname="foo-%-msys-%-src.tar.lzma" /> <licence tarname="foo-%-msys-%-lic.tar.lzma" /> or we may exploit an extension I've added to the template substitution code, allowing inheritance of the same type as the associated binary: <source tarname="foo-%-msys-%-src.tar.%" /> <licence tarname="foo-%-msys-%-lic.tar.%" /> or even: <source tarname="foo-%-msys-%-src.%" /> <licence tarname="foo-%-msys-%-lic.%" /> to inherit the entire "tar.lzma", or whatever. Finally, in addition to this compression type mapping issue, I've also identified an anomaly specific to the msys-core package specification; the tarname: msysCORE-1.0.17-1-msys-1.0.17-bin.tar.lzma conveys no canonical relationship to the package name, msys-core. (This affects the implementation, which I've also added to CVS, of the capability to anonymously upgrade all installed packages). The easiest work around for this is to add an alias: <package name="msys-core" alias="msysCORE"> so, while the anonymous upgrade capability deserves its own separate discussion thread, it may be expedient to address both issues at the same time. -- Regards, Keith. |
From: Keith M. <kei...@us...> - 2011-10-09 18:08:00
Attachments:
mingw-dist-20111009-1.diff.xz
|
Attached patch addresses... On 08/10/11 10:42, Keith Marshall wrote: > ... my own testing has revealed a weakness in our mingw-dist > manifests; specifically: > > <source tarname="foo-%-msys-%-src.tar" /> > > is not sufficiently deterministic to identify the name of the source > tarball -- the compression type is indeterminate. Likewise for: > > <licence tarname="foo-%-msys-%-lic.tar" /> ...this... > I think we should fix this, before progressing a roll out. I don't like > the idea of an heuristic bodge, to guess a missing compression type, so > we may either include it explicitly, e.g.: > > <source tarname="foo-%-msys-%-src.tar.lzma" /> > <licence tarname="foo-%-msys-%-lic.tar.lzma" /> > > or we may exploit an extension I've added to the template substitution > code, allowing inheritance of the same type as the associated binary: > > <source tarname="foo-%-msys-%-src.tar.%" /> > <licence tarname="foo-%-msys-%-lic.tar.%" /> ...this mechanism, i.e. append ".%" to represent compression type, in all cases where it isn't specified explicitly. (This requires that all component packages within each individual release, including source, must be packaged with the same compression type; this probably isn't too much of a hardship). This patch also addresses... > Finally, in addition to this compression type mapping issue, I've also > identified an anomaly specific to the msys-core package specification; > the tarname: > > msysCORE-1.0.17-1-msys-1.0.17-bin.tar.lzma > > conveys no canonical relationship to the package name, msys-core. (This > affects the implementation, which I've also added to CVS, of the > capability to anonymously upgrade all installed packages). The easiest > work around for this is to add an alias: > > <package name="msys-core" alias="msysCORE"> ...this. Okay to commit, and publish? -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2011-10-11 02:07:00
|
On 10/9/2011 2:07 PM, Keith Marshall wrote: > Okay to commit, and publish? Yep, go ahead. -- Chuck |
From: Keith M. <kei...@us...> - 2011-10-11 18:56:38
|
On 11/10/11 03:06, Charles Wilson wrote: > On 10/9/2011 2:07 PM, Keith Marshall wrote: >> Okay to commit, and publish? > Yep, go ahead. All done. -- Regards, Keith. |