I've created an ebuild that uses the original windows cds to install the nwn data with unshield and biounzip instead of downloading the 1,2 GB of resources. Note that this ebuild only uses GPL software and no wine for the extraction. As it is a quite complex work and I am not that expirienced with writing ebuild I would like to hear your oppion about it.
Created attachment 76660 [details] nwn-data-1.29-r1.ebuild
Created attachment 76661 [details] biounzip-1.1a.ebuild Needed to extract the data on the second CD
Funny enough, I was just looking into this. I won't be adding your nwmouse hack, though, as you can see there is already a bug for adding it as a separate ebuild (which is how I think it should be).
I've added biounzip to portage... I'm trying to figure out the best way to incorporate your changes for the CD set into the ebuild, since I am trying to add support for all of the differing CD sets.
Worked fine here for me! Just a few bugs/things I had to change: 1. biounzip in portage is in games-util 2. the language files can all be found here (no fileplanet registration etc.): http://nwn.bioware.com/downloads/linuxclient.html#lininstall 3. unshield is giving an error (no 'x' needed to be given here): * Found CD #1 root at /mnt/dvd >>> Unpacking source... * Unpacking files... Failed to open x as an InstallShield Cabinet File
Perhaps I got an idea how to manage nwn installation nicely. The nwn ebuild has useflags for all official expansions and all the modules. Each expansion and module (also the pay modules) have a seperate ebuild. All the ebuilds have several seperate sources possible: online, NWN CD, the single expansion CDs, Gold, Platinum, Diamond, Collector's edition and file. So when users have downloaded the paymodules, they can just put them in distfiles and the ebuild will find them. That would be a lot of ebuilds, but I think with an eclass which manages content installation (like the mod eclass for Quake3) this could be realized in a very nice way. Ebuilds needed: nwn itself original nwn data Shadows of Undrentide Hordes of the Underdark Shadowguard (must have a "no Witch Wake" dep, because it is included in Shadowguard) Kingmaker Pirates of the Sword Coast Infinite Dungeons Witch Wake (must have a no Shadowguard dep) I guess, that's it, please tell me what you think.
>>Quote Chris Gianelloni: >I'm trying to figure out the best way to >incorporate your changes for the CD set into the ebuild, since I am trying to >add support for all of the differing CD sets. Chris Gianelloni, is this a solution for what you try? Oh, and bug 139196 has to be fixed first. I hope it is ok that I post all of this in this bug report. If not, I'll open a new one. Sorry for double posting.
I *definitely* don't want to support a ton of ebuilds. NWN is a big enough PITA without expounding on the problem by splitting it up into a ton of ebuilds w/ lots of USE combinations. Honestly, I'm working a 2006.1 and this is pretty low priority right now.
1] biounzip is not working (at least on amd64) - writes message "Buffer not large enough". Looks just like a bug in handling zlib code. I'll try to fix it myself. If I'm wrong, please tell me. If I'm not wrong, I'll file a bug with fixes in a few days. 2] there's bad unshield syntax in ebuild nwn-data-1.29-r1.ebuild. 'unshield x <file>' should be replaced with 'unshield <that file>'. (line 274) 3] There should be better information about "What CDs the user should prepare&mount" available without ebuild hacking My opinion is that CDROM_SET's in ebuilds are bad, and should be solved by telling users 'where to copy these files', eventually 'how to unpack them'. In this case, some script could be provided. (BTW this would make nwn-data unnecessary) cheers [exa]
OK, fix is here (quite simple, after one reads zlib...) biounzip-1.1a.tar.gz, file biounzip.c, lines ~163-170 fread((char *)&size_uncompressed,1,4,fp); fread((char *)&size_compressed,1,4,fp); fread(srcbuffer,1,size_compressed,fp); + size_uncompressed=512000; /*size of the buffer allocated above*/ returnval=uncompress(dstbuffer,&size_uncompressed,srcbuffer,size_compressed); if(returnval==Z_OK) { fwrite(dstbuffer,1,size_uncompressed,outfile); }else if(returnval==Z_BUF_ERROR){ now workx OK on amd64. Second thing, (in ebuild) there's no check whether make failed or not, so someone should add ||die to lines 21 and 22 (if make fails because of some weird reason and the build doesn't really die, biounzip gets clearly emerged without the real biounzip binary...) Please someone make a patch and add it to portage. (I'm gonna probably make it and post it here in a few days myself, if I have enough time) Thanks, [exa]
(In reply to comment #9) > 1] biounzip is not working (at least on amd64) - writes message "Buffer not > large enough". Looks just like a bug in handling zlib code. I'll try to fix it > myself. If I'm wrong, please tell me. If I'm not wrong, I'll file a bug with > fixes in a few days. I'll look at this. I cannot duplicate this, however, and my primary development platform is amd64, so it has been tested there, extensively. > 2] there's bad unshield syntax in ebuild nwn-data-1.29-r1.ebuild. 'unshield x > <file>' should be replaced with 'unshield <that file>'. (line 274) Hrrrmn... can you remove the unshield line for amd64 from the ebuild and test it with unshield 0.5 (which is the latest version, I think) and see if it works. I'd limited amd64 to unshield 0.2 for some reason, and I cannot remember why at the moment. > 3] There should be better information about "What CDs the user should > prepare&mount" available without ebuild hacking Huh? What's wrong with the information? It tells the user exactly which CD to mount, so I'm not sure where the confusion is coming from on this. > My opinion is that CDROM_SET's in ebuilds are bad, and should be solved by > telling users 'where to copy these files', eventually 'how to unpack them'. In > this case, some script could be provided. (BTW this would make nwn-data > unnecessary) Ehh... never. It will remain in an ebuild as long as I have anything to do with it. Doing anything outside the package manager for a package is a poor idea and something that I will never agree to do.
seems like this is probably fixed with the lateste ebuild in portage. reopen if not.
