On Tue, Jul 16, 2013 at 08:50:08PM +0200, Corinna Vinschen wrote: >On Jul 16 14:18, Christopher Faylor wrote: >> On Tue, Jul 16, 2013 at 08:09:14PM +0200, Corinna Vinschen wrote: >> >On Jul 16 11:04, Christopher Faylor wrote: >> >> On Tue, Jul 16, 2013 at 11:37:17AM +0100, Jon TURNEY wrote: >> >> >On 16/07/2013 03:08, Christopher Faylor wrote: >> >> >> On Mon, Jul 15, 2013 at 09:49:12PM -0400, Ken Brown wrote: >> >> >>> setup-x86_64.exe behaves differently from setup64.exe with respect to >> >> >>> source-only packages. (I don't know which one is "right".) This is >> >> >>> showing up for me because the 64-bit versions of gcc and readline are >> >> >>> source-only packages that are (incorrectly?) required by other >> >> >>> packages. >> >> >>> setup64.exe seems to ignore these requirements, whereas >> >> >>> setup-x86_64.exe wants to install the packages but then reports >> >> >>> "Incomplete download". >> >> >> >> >> >> Thanks for trying this. I doubt that is anything that I introduced. >> >> >> >> >> >> Do you see the same behavior from setup-x86.exe? >> >> > >> >> >In x86, readline is the devel package, and so has source and binary tar >> >> >files. >> >> > >> >> >In x86_64, the packaging is different and a libreadline-devel package >> >> >has been >> >> >added, so readline is now source only, but has things which depend on it >> >> >(e.g. >> >> >gawk, gdb, python) becuase they haven't been updated for this change. >> >> > >> >> >It seems setup reports trying to install a package for which it knows no >> >> >versions with the helpful message "Incomplete download" :-) >> >> >> >> It seems like these issues are being fixed but should we modify setup's >> >> behavior to be less "helpful"? >> >> >> >> Hmm. I wonder if upset could also report on these problems as well. >> > >> >In upset it be more useful, imho, because we get immediate warning >> >when the problem occurs. >> >> I can do that but was there a setup regression here? It sounded like >> the old setup64.exe doesn't complain about these issues. Or does it >> complain now with the lastest packages? > >The former setup64 doesn't complain, but I don't think this is a setup >problem. Rather, it's a difference between the generated ini files. >The old setup64.ini was only generated by genini, the new by upset. > >For instance, here's the gcc entry generated by genini: > > @ gcc > sdesc: "GNU Compiler Collection" > ldesc: "The GNU Compiler Collection includes front ends for C, C++, > Objective-C, Fortran, Java, Ada, and Go, as well as libraries for these > languages (libstdc++, libgcj,...)." > category: Devel > >And here's the gcc entry as generated by upset: > > @ gcc > sdesc: "GNU Compiler Collection" > ldesc: "The GNU Compiler Collection includes front ends for C, C++, > Objective-C, Fortran, Java, Ada, and Go, as well as libraries for these > languages (libstdc++, libgcj,...)." > category: Devel > version: 4.8.1-1 > source: x86_64/release/gcc/gcc-4.8.1-1-src.tar.bz2 87070214 > eb70273d8a2a555d995b0675980fcc1c > [prev] > version: 4.8.0-2 > source: x86_64/release/gcc/gcc-4.8.0-2-src.tar.bz2 86977149 > 128658603c4daac97e62b4778c22a56d > >So in one case the entry doesn't contain any package, in the other >case we have "source" entries. With the same input, I bet setup64 >behaves the same as setup-x86_64. > >[...time passes, testing...] > >yes, when using the new setup.ini with the old setup64.exe, the effect >is the same.
Thanks for checking. Sounds like a genini bug. I've uploaded a new upset which checks for this corner case problem. cgf