[Slackbuilds-users] nvidia-driver.info missing 64bit file info

King Beowulf kingbeowulf at gmail.com
Tue Jul 16 06:57:28 UTC 2013


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
> anyway.
> 
> Seriously, though, if you don't want to do it or don't have time,
> that's fine.
> 
> -RW
> 
> 
> 

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). 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...

-Ed


More information about the SlackBuilds-users mailing list