From: Earnie <ea...@us...> - 2011-11-08 20:40:11
|
Charles Wilson wrote: > On 11/8/2011 9:56 AM, Earnie wrote: >>> (although msys-bsdtar is included in mingw-developer-toolkit; it >> >> I don't think it should be. > > You know, there was a time when we discussed all these things, and > talked about what packages should and should not be included in > msys-base, mingw-developer-toolkit, etc. > > http://thread.gmane.org/gmane.comp.gnu.mingw.devel/4058/focus=4078 > It appears that I was silent. > I'm starting to get a little frustrated by all this second guessing. A > few days ago it was about the contents of msys-base. Now it's about the > contents of mingw-developer-toolkit. And the rehashing keeps popping up > as threadjacks, which is doubly annoying. > Hardly, intended to frustrate you. > > But you seem initially to be asserting a stronger propostion: not simply > that msys-bsdtar (msys-bsdpio, msys-libarchive) be removed from > mingw-developer-toolkit going forward, but that they be removed from > mingw.org entirely. I mildly disagree with the former (obviously), but > strongly disagree with the latter. > No, just trying more to understand why we need more than one tar. Since msys-bsdtar supplies all that is needed for MinGW why not just use it and drop msys-tar? Or if that is too much then just leave it to the user to grab it. I found it amusing that David Hoyt states he uses mingw32-bsdtar in his mail relating to missing dependencies and as you state he should be using msys-bsdtar. >>> supports more formats than GNU tar, including .iso (readonly), .cpio, >>> .zip, mtree, shar, ...). >> >> This becomes a better reason to have it but still not a good enough >> reason to include it in the DTK. > ... >> Okay, I've not ever had a need to use bsdtar in MSYS. > > I did, back when msys-tar was 1.13 or so. At the time we (a) did not > yet have a mingw-get installer, and (b) many of our packages still had > very strange internal structure. Some "binary" packages were > bob-1.2.3/{bin/*,share/*,lib/*}, others were mingw/{bin,share/lib}, and > still others were /bin,/share,/lib. > > So...IIRC, bsdtar supported '--strip-components=N' and our old version > of tar did not -- plus there were early issues with gnu tar + lzma (e.g. > I think you had to do 'tar --use-compress-program=lzma' or something > ugly like that). Ack. > >> And having mingw32-bsdtar, installing msys-bsdtar becomes needless >> because mingw32-bsdtar would always be found first unless you're >> developing in MSYS developer mode giving another issue to including it >> in the DTK. > > Not exactly -- first, because while msys-bsdtar is currently installed > as part of the mingw-developer-toolkit, mingw32-bsdtar is not. > Therefore, "typical" users who invoke 'bsdtar' from an msys shell, even > in its normal "Hi-I'm-mingw32" mode, would get the msys version. Only > those who explicitly select and install the mingw32 version would get > it. Presumably they did so for a reason, and get to keep all the pieces > if something breaks. > So, the announcement entices the MinGW user to install both mingw32-bsdtar and msys-bsdtar. > Secondly, because some features of bsdtar (actually, libarchive, but > let's not quibble) require external libraries for which we (had/have) no > mingw32 version (e.g. expat at first, plus openssl), the msys-bsdtar is > more featureful than the mingw one. > Ok, so there are dependencies in msys-bsdtar that aren't delivered in msys-base which is a reason to have both msys-tar and msys-bsdtar. >> The DTK was developed for tools typically needed for >> development and a native version wasn't easily usable within MSYS. > > With regards to bsdtar, I viewed it the other way around: because we had > support for (libxml, libexpat, openssl) under msys, I could build a > full-featured version that passed almost all of its internal testsuite > and skipped very little. In fact, I joined the project, helped to > rewrite most of its build system -- while arguing for retaining the > autotool based system rather than deprecating that in favor of cmake -- > and got it patched to support cygwin, msys, and mingw (ditto for xz, BTW). > Ack. > But, for those who wanted more-than-basic-bsdtar AND wanted to avoid > MSYS, I could provide a tar(1) implementation for them that was *fairly* > complete, but still had significant weaknesses when compared to the > "real" one -- that is, msys-bsdtar: > > 1) no support for .mtree (later slightly relaxed, once mingw32 > subsys gained mingw32-libexpat; but still no support for > cryptographic hashes because no openssl) > 2) no support for archives which contain symbolic links; IIRC > mingw32-bsdtar will exit with error if you try to unpack one... > 3) no support for xar (later relaxed, with addition of mingw32- > libexpat) > Ack. > So, originally, mingw32-bsdtar (well, actually, mingw32-libarchive) was > provided for two reasons: (1) because it'd be a nice addition for those > who wanted to use only native tools with no MSYS, but for whom the very > limited basic-bsdtar was insufficient, and (2) because it came for > "free" with mingw32-libarchive, and (at the time, pre-mingw-get) I was > thinking that mingw-get could use libarchive to support its operation. > > As it happened, mingw-get instead uses liblzma, libz, and libbz2 > directly for (de)compression support, and implements ONLY 'tar' format > (de)archive support -- and does so internally. So, it doesn't use > libarchive. > > IMO, the argument between msys-bsdtar and mingw32-bsdtar is just like > the "argument" between msys-bzip2 and mingw32-bzip2: if we have > mingw32-bzip2, why not just remove msys-bzip2? Except that misses an > important issue, which applies in both the bzip2 and bsdtar cases: the > mingw32 *application* is, in many ways, a *side effect* of needing the > *library* for that subsystem. E.g. mingw-get needs (mingw32)libbz2.a -- > and we get (mingw32)bzip2.exe "for free" -- but that doesn't supplant > the msys-bzip2, because bzip2.exe is often used in pipelines, and those > just plain work better if both 'sides' of the pipe are msys -- error > return value propagation, etc. > Good points - Ack. > Ditto liblzma/xz. Ditto ditto (mingw32)libarchive.a and > (mingw32)bsdtar.exe -- except that we don't, actually, need libarchive.a > [I thought we would, but mingw-get went another direction]. > Good points for -dev but not exactly -bin. > ===== > > I believe that all four 'tar' implementations are complimentary, and > fulfill different needs. In a *basic* msys installation, gnu tar is the > obvious choice, as the *nix de-facto standard. In a development > environment, our users might have need of the extensive alternative > formats that msys-bsdtar provides (ever wanted to poke around in the > contents of an .iso on win32, without installing a Windows Driver and > 'mounting' it?) > Ack. > Some users may wish to eschew MSYS altogether, but still need a > relatively capable tar(1) implementation -- for those users, > mingw32-bsdtar is the answer. > > And finally, sometimes you just need a quick and dirty self-contained > tool to unpack .tar.[gz|bz2|lzma|xz] on a windows box, and don't want > to, don't need to, or are not allowed to, install a mingw32 or MSYS > environment. That's what basic-bsdtar.exe is for. > > However, if one of those four were to be removed from mingw.org, I'd > argue that mingw32-libarchive/bsdtar should be the one, not > msys-libarchive/bsdtar. Given that one might not want MSYS, I can see leaving both. But your points and mine bring up the question of mingw-get needing a <conflicts /> tag? While mingw32-libarchive is needed for possible MinGW development msys-bsdtar should be the choice for the user wanting more decompression options in a tar and mingw32-bsdtar would get in the way if both are installed. Your lengthy response gives someone who may need to take over one day for Chuck some reasoning behind it. Regards, -- Earnie -- http://www.for-my-kids.com |