Bugzilla Bug 118446

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 an attachment (id=76660) [edit]
nwn-data-1.29-r1.ebuild

Created an attachment (id=76661) [edit]
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.