[Slackbuilds-users] nvidia-driver.info missing 64bit file info
c.willing at uq.edu.au
Tue Jul 16 07:23:43 UTC 2013
On 16/07/2013, at 4:57 PM, King Beowulf <kingbeowulf at gmail.com> wrote:
> On 07/15/2013 10:52 PM, Robby Workman wrote:
>> On Mon, 15 Jul 2013 20:31:58 +0100
>> "Greg' Ar Tourter" <artourter at gmail.com> wrote:
>>> Hi Robby,
>>> Well looking through the repository, the nvidia-driver (and
>>> avr8-gnu-toolchain, but that's only for the pdf manual) packages are
>>> the only ones with files in common. So asking to download both
>>> version seems rather a waste of bandwitdh
>> Okay, fair point.
>>> Moreover, for some packages (ucsc-blat, p4, p4v ), the source file
>>> name is the same for 32 and 64 bit version but are downloaded from
>>> different locations and have different checksum. in these case, wget
>>> with append .1 to the second one and therefore making the slackbuild
>>> use the 32bit version instead.
>> Oh wow, I wasn't aware of that.
>> Given all of this and erik's reply, I think it's probably a good
>> change to make.
>> Don't feel obligated to do this, as I don't mind doing it myself,
>> but since I'm a bit tied up on another project right now, patches
>> for all of the affected stuff would make this easier :) Also,
>> since you pointed it out, you should be credited with the fixes
>> Seriously, though, if you don't want to do it or don't have time,
>> that's fine.
> Well, the question I have, as a script maintainer, what will be the
> policy going forward? This is a bit of a chicken/egg problem as well:
> do we fix SBo to work with how sbopkg does things, or does sbopkg change
> to accommodate SBo?
> Perhaps an idea is, instead of increasing the complexity/redundancy of
> the .info file, we fix the sbopkg to correctly deal with the 32/64
> downloads (re: Greg's examples; you only get ONE source file block -
> pick one). For cases like nvidia-*, we separate out the utilities into
> a separate arch agnostic package, with the nvidia-driver package just
> for the 2 arch downloads.
> Simplicity == Ruggedness == Stability
> Personally, I volunteer to assist SBo, and don't really give a fig about
> sbopkg (popular though it is).
I don't use sbopkg but have my own build system wrapping SBo's. If building for x86_64, it uses the DOWNLOAD_x86_64 field if its not empty, otherwise uses whatever is in the DOWNLOAD field. 32bit builds use just the DOWNLOAD field. Isn't that the way its supposed to work i.e. DOWNLOAD_x86_64 only contains something if something x86_64 specific is needed, otherwise the ordinary DOWNLOAD field contains whatever is needed?
I'm not sure what the use case would be to download both.
> Unless, of course, sbopkg is now an
> officially sanctioned SBo utility - similar to how slackpkg is now in
> the official Slackware tree. Although, I doubt the slackpkg team us
> telling our BDFL how to fix his package tree to make it easier for them…
Yes, I agree; fix the non conforming stuff rather than cater to it.
More information about the SlackBuilds-users