From: Charles W. <cwi...@us...> - 2010-04-22 23:43:10
|
On Thu, 22 Apr 2010 15:42 +0000, "Keith Marshall" wrote: > On Thursday 22 April 2010 03:41:47 Charles Wilson wrote: > > This is a developer thing. I think most of us are comfortable > > using either spelling; > > Well obviously, easiest and least painful is to leave it just as it > is; unless anyone else objects very strongly, (and very quickly), > let's agree that it will remain as the GB spelling of "catalogue". Fine by me. > > I might have to draw the line if I saw: > Which of course, wouldn't be possible anyway, (with TinyXML), as you > subsequently discovered... > > It looks like you're right, Keith -- we have only two choices: > > don't specify the encoding at all, and hope it works, or specify > > UTF-8 and politely request that folks avoid all but low-ascii > > printable characters in entity NAMES. > > That's what I thought; thanks for researching it. Sure. > > I've attached a tentative version of the xml for the > > "zlib package": > > Thanks! At a cursory glance, it looks reasonably close. I'll fold > it into my development sandbox, play with it later, and get back to > you. Just a few initial comments:-- OK. I'll hold off on trying to construct any other packages -- except maybe the gettext collection, since it has already come up and presents additional questions -- until we get this one nailed down, vis: > * I've been writing issue attributes as YYYYMMDDNN, where NN is just > a serialisation count. "mingw-get update" will simply ignore any > downloaded package-list, if its issue attribute doesn't increment > over any corresponding locally cached version. The comparison is > performed lexically, so your use of YYYYMMDDHHMM will work just as > well, but are we really likely to have more than 99 updates to any > one package-list in any single day? It's not a big deal, but we > should adopt one convention or the other, and then stick with it. I'll probably automate the 'commit' step -- obviously, adding elements to reflect a new release is a manual process. But once that's done, a simple a script that (a) updates the attribute, (b) checks in to CVS, (c) compresses using lzma, and (d) uploads the .lzma to <where-ever> on sourceforge -- would be my typical approach. And... TIMESTAMP=`date +%Y%m%d%H%M` cat foo | sed -e "s/@@TIMESTAMP@@/$TIMESTAMP/" > newfoo && mv newfoo foo is a lot more straightforward -- and robust -- than OLDTIMESTAMP=$(cat foo | sed -n -e '/pattern/s/^.*\(the good stuff\).*$/\1/p') OLDSEQ=${OLDTIMESTAMP:8} NEWSEQ=$(( $OLDSEQ + 1 )) NEWTIMESTAMP=`date +Y%m%d`${NEWSEQ} since I don't have an xml parser coded in bash handy. > * I don't think the -dev component needs to specify *any* "requires" > dependencies; Disagree...see below > certainly not msys-gcc or msys-w32api. I could go along with *that* part... > Does it need > the -dll component for -dev deployment? I suspect not. But this assertion contradicts the behavior of all unix systems. In every system I can recall, the -devel package always depends on the lib package (this makes sense, because for *native* builds, you wouldn't be able to run 'make check' on the package the depends on the -devel package, unless you also installed the matching lib package for that dependency). Also, devel packages all tend to have dependencies on the other devel packages used to build them -- for instance, libpng-devel depends on libz-devel (ne' zlib-devel, depending on your distro). The question is, how far back down the chain to go: I can see the argument for cutting the "dependency chain" just ahead of the actual compiler stuff, since on a cross-build system you wouldn't need *mingw/msys's* version of the compiler anyway. But, you WOULD need msysCORE-dev (and if you were using a port of mingw-get to populate your sysroot, you probably would like for it to handle all of the -devel deps, EXCEPT for those directly related to the compile toolchain). (*) side note, for later discussion: "sysroot" installations would need a post-install step to "fixup" the ${root}/lib/*.la files, and any ${root}/bin/{pkg}-config scripts, ditto ${root}/lib/pkg-config/*.pc, ... I dunno if this sort of thing is even worth thinking about. > * There are five supported selectors for "requires" specifications; > ("lt", "le", "eq", "ge" and "gt"). If you think the -dll really is > a prerequisite of the -dev component, then > > <requires eq="msys-zlib-%-msys-%-dll.tar" /> > > is the correct representation for an exactly equal version match, > (when I get it working; it will error out right now). OK. > * When you write the "requires" specification, the match string has > the form of a canonical tarname, but the package-name part *must* > match the "name" attribute of the containing "package" definition, > irrespective of the actual tarname of the target download. Err...I'm confused. > You've > named this "package" as "msys-zlib", (which I think is a practice > we should formally adopt -- prefix the subsystem name to the name > of the package, in the "package" definition, to avoid any potential > ambiguity [*]), ... > [*] We should probably do likewise, in the actual XML file name, so > the package-list spec to include this zlib package would state > > <package-list catalogue="msys-zlib" /> > > resulting in "msys-zlib.xml", (which would be hosted for download as > "msys-zlib.xml.lzma"). OK, that's all good. > so the form I've shown above is correct. (BTW, the > ".tar" at the end is required, to satisfy pkginfo's parsing rules, > but it doesn't participate in the actual dependency resolution > matching operation; it could just as well be specified as ".foo", > and it would still work). But my confusion is this: if the "package name" is "msys-zlib", does that mean that **all** the <release> tags need to specify themselves as: <release tarname="msys-zlib-1.2.3-2-msys-1.0.13-dev.tar.lzma"> <download tarname="zlib-1.2.3-2-msys-1.0.13-dev.tar.lzma" /> </release> > > > Here you would edit the *existing* gettext.xml, (which would > > > likely define four packages within its package-collection)... > > > > Why four, and not just one, with eight components? > > I'm thinking that users may wish to do: > > $ mingw-get install msys-libintl-dll > > (for example), without necessarily being concerned that it is really > a subsidiary of msys-gettext; to make that work, you either define a > specific package with name="msys-libintl", to furnish the "dll" > component, or you define one "msys-gettext" package, with additional > "alias=..." attributes, (actually one attribute with value as a space > separated list), to identify the subsidiaries. > > In addition to this, you also face a problem with identification of > individual dll component packages with disparate names, if you embed > them all within a single package -- lookups are based on the name > and alias attributes of the "package" element, and the class > attribute of the contained "component" element, so mingw-get will > have a harder job determining which particular "component" is > intended, when faced with this disparity, (both in the case of user > specified lookups, and for dependency resolution). Sure, that > wouldn't be an insoluble problem, but it ain't the way it works at > the moment. I see; that makes sense. Now, zlib isn't a good example here, but going back to gettext, I'd need to specify, for each of the four packages, a <source ...> element, as well as a "lic" component (see far below): otherwise, mingw-get won't "know" that the license tarball and source tarball for pkg "msys-libintl-dll" is provided by tarname="{msys}-gettext-%-msys-%-lic.tar" and tarname="{msys}-gettext-%-msys-%-src.tar", respectively. And no heuristic would ever be able to figure it out. > > OK. But, whether the back-end logic is complete, is the front-end > > parsing ready (in mingw-get-alpha-2)? > > Strictly no, but... > > > That is, can I go ahead and > > include, where necessary, a <source> tag -- that will simply be > > ignored by mingw-get for now? > > ...yes, you can. There is no formal XML schema (or DOM definition) > to restrict which elements are allowed, and in which contexts, (and > in any case, TinyXML doesn't support validation against a DOM); the > only strict requirement is that the XML /structure/ is valid. You > can add any arbitrary element, or attribute you wish, in any [**] > context, and mingw-get will silently ignore it, if it isn't > specifically looking for it. OK -- I can live with that. (I'm used to validating parsers with DOM or schema support...) > > (*) should -dev packages list gcc-msys as a requirement? > > As a general rule, I think not. OK. > > The > > header files (zlib.h) #include other headers that are supplied > > only by gcc, but...that would pull in a lot of extra stuff if > > somebody just wanted to, say, install zlib-dev to simply look at > > the headers. Ditto w32api-msys... > > Certainly, there may be an implied requirement for headers from the > GCC package, and from the w32api package, but these don't become > explicit until actually trying to *compile* the package, and the > installation of the compiler suite is an obvious prerequisite to > doing that, irrespective of any implied dependencies in an auxiliary > library package. Thus, I think that msys-gcc-bin should specify its > dependency on msys-w32api-dev, but not vice-versa, OK. > and there is no > need for msys-zlib to specify any dependency on either. In this case, I can go along with that (e.g. w32api-dev is pretty close to the "bottom" of the stack, that it could fall under my "leave out the compiler/core-system-related dev files" rule). But, I'd think that libintl-dev, for instance, should require libiconv-dev (even though building gettext itself requires lots more stuff, including expat-dev, termcap-dev, etc -- but the *library*, libintl, doesn't depend on those things). IOW, if project "foo" says "you need to install libintl-dev" to compile this package -- but foo doesn't directly depend on libiconv-dev, I want libiconv-dev to get installed automatically when I dutifully traipse off to install libintl-dev; if it doesn't, then I'll get a compile-time error that I was not expecting, since the libiconv headers (and libiconv import lib) are missing -- and I won't know why. But I do *not* need libexpat-dev just to compile something that requires libintl; libexpat itself is used only by the gettext apps, not the gettext libs. > Oops! I see your point, now. One possibility would be to have the > msys-base.xml file specify just the msys-base package specification, > together with a bunch of package-list elements to pull in the rest. > Alternatively... Whichever. > > Then, the file you called 'msys-base.xml' would instead be called > > 'msys-master.xml', > > ...this would be equally acceptable -- maybe better. Ultimately, I > think it should be you and Cesar who decide on your preferred layout, > but clearly, I shouldn't abdicate all responsibility in helping you > to formulate your choice. Well, the top-level layout is more a question of, what does/will mingw-get support. I'd be perfectly happy to just provide content in the form of appropriate msys-*.xml and mingw-*.xml fragments for specific packages, and let somebody with a better understanding of the mingw-get innards handle marshalling them together. Hint... Of course, all of that -- including said .xml fragments -- will be subject to commentary and revision driven by discussion on this list. > Well, most of the code to handle it is already written, (and used > to segregate the installation manifests), but it will need some book > keeping, to track the name changes as the downloads are moved into > the local cache directory. However, you are right; it likely isn't > especially urgent. I can't remember; were you planning to use a database backend of some kind, or just flat files, to manage the *installation manifest(s)* [as opposed to the *distribution manifest(s)]? > > Exit question 1: can msys-bash-bin list msys-base as one of its > > requirements, even though msys-base lists msys-bash-bin as one of > > its own requires? E.g. circular deps? > > I *think* I got the logic right, to break circular dependency specs, > but why would you want to do this? Surely, there is only one actual > prerequisite for msys-bash-bin, and that is msysCORE-bin. Don't > specify a dependency unless it is absolutely necessary, otherwise > you preclude the possibility of installing an even more minimal > subset of MSYS than msys-base specifies; (it is conceivable, no > matter how unlikely, that I might want just a shell, without > incurring the overhead of other packages typically included within > msys-base). Hmmm...good point. I was kind of thinking that "everything should require msys-base" (just like "everything requires cygwin" in the cygwin distro) -- to the point that we could add that implicitly within mingw-get's logic. But that got me thinking about the circular deps inherent in such a scheme. But...my assumptions were incorrect; nothing in *MinGW* requires msys at all. And, the whole point of msys is to be minimal; if somebody explicitly wants to experiment with a "crippled" sub-minimum installation, who are we to say no? > > Exit question 2: should ALL packages reference their own -lic > > package (if they have one) as an explicit requirement? > > Until you asked, I hadn't given it a great deal of thought. On > balance, I'm inclined to say "yes, I think so", which then begs the > question: should mingw-get implicitly add a -lic dependency, for > every package component which has a -lic sibling? Or maybe, we > should just add an explicit: > > <requires eq="pkgname-%-subsys-%-lic.tar" /> > > as a single sibling prerequisite of the *component* elements within > the package definition? (Subject, of course, to me getting the "%" > wildcard matching working fairly sharpish). Actually, I think a better approach would be something similar to the <source ...> element: an optional <lic ...> element if the -lic tarname can't be "guessed" -- e.g. the "lic" component for msysCORE-bin, msysCORE-dev, and msysCORE-dbg is actually msysCORE-bin. Granted, both msysCORE-dev and msysCORE-dbg *already* require the -bin package for other reasons, but the principle remains. Then, we could make a policy decision as to whether mingw-get would implicitly always install the matching lic component, or not. I think this to-install-lic-or-not decision should NOT be left to 'did the packager remember to add <requires eq="*-lic">'...maybe mingw-get could default to always installing lic packages, but with a top-level flag or cmdline argument --i-dont-care-about-licensing. -- Chuck |