LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 01-12-2010, 06:06 AM   #1
jong357
Senior Member
 
Registered: May 2003
Location: Columbus, OH
Distribution: DIYSlackware
Posts: 1,914

Rep: Reputation: 52
cdrtools.SlackBuild 64bit


First off, I really hate the shily make system. That being said, I just spent quite a bit of time screwing with cdrtools to make it multilib compliant.

Look it over or not, just thought I'd toss it out in case anyone wanted to add

LIBDIRSUFFIX="64"

to it...

Code:
sed -i "s/^COPTOPT=.*/COPTOPT=$SLKCFLAGS/g" RULES/cc-*.rul
grep -rl '/etc/default/cdrecord' . | xargs sed -i \
   's@/etc/default/cdrecord@/etc/cdrecord.conf@g'
grep -rl 'share/doc' . | xargs sed -i 's@share/doc@doc@g'
find . -name "*.mk" | xargs sed -i \
   -e "s@lib/siconv@lib$LIBDIRSUFFIX/siconv@g" \
   -e "s/INSDIR=\s*lib\s*$/INSDIR=lib$LIBDIRSUFFIX\n/g"
sed -i "s@lib/siconv@lib$LIBDIRSUFFIX/siconv@g" libsiconv/sic_nls.c \
   mkisofs/diag/isoinfo.c \
   mkisofs/mkisofs.c \
   libsiconv/tables/Makefile
INS_BASE=/usr DEFINSGRP=root make -e $NUMJOBS || exit 1
# Without this second run, cdda2wav is skipped...
INS_BASE=/usr DEFINSGRP=root make -e || exit 1
INS_BASE=$PKG/usr DEFINSGRP=root make -e install || exit 1
cat cdrecord/cdrecord.dfl > $PKG/etc/cdrecord.conf.new
rm -rf $PKG/usr/{sbin,doc/rscsi,man/man1/rscsi.1}
 
Old 01-12-2010, 07:46 AM   #2
voyciz
Member
 
Registered: Mar 2004
Distribution: Slackware
Posts: 425

Rep: Reputation: 40
Err...do you realize that Slackware64 ships with cdrtools and the build script is included with the source?
 
Old 01-12-2010, 07:53 AM   #3
~sHyLoCk~
Senior Member
 
Registered: Jul 2008
Location: /dev/null
Posts: 1,173
Blog Entries: 12

Rep: Reputation: 129Reputation: 129
Check /ap
 
Old 01-12-2010, 08:24 AM   #4
jong357
Senior Member
 
Registered: May 2003
Location: Columbus, OH
Distribution: DIYSlackware
Posts: 1,914

Original Poster
Rep: Reputation: 52
Er.... Do you realize that Slackware dumps cdrtools straight to /usr/lib?

I think you guys missed my whole point.

Quote:
Originally Posted by jong357 View Post
....to make it multilib compliant.
Besides, I totally quoted the official SlackBuild comment in my code box....

Last edited by jong357; 01-12-2010 at 08:29 AM.
 
Old 02-21-2010, 07:33 AM   #5
jong357
Senior Member
 
Registered: May 2003
Location: Columbus, OH
Distribution: DIYSlackware
Posts: 1,914

Original Poster
Rep: Reputation: 52
Any word on this Eric, Robby or Pat?

As a matter of correctness, this should be taken care of....
 
Old 02-21-2010, 08:00 AM   #6
forum1793
Member
 
Registered: May 2008
Posts: 312

Rep: Reputation: 34
Just out of curiosity, what are you running that MUST be 32 bit that requires or interacts with the cdrtool programs?
 
Old 02-21-2010, 08:23 AM   #7
jong357
Senior Member
 
Registered: May 2003
Location: Columbus, OH
Distribution: DIYSlackware
Posts: 1,914

Original Poster
Rep: Reputation: 52
Nothing... What does that have to do with anything. /usr/lib should be completely empty on a 64bit system unless they are 32bit libs.

As I've already said....

"As a matter of correctness, this should be taken care of...."
 
Old 02-21-2010, 08:59 AM   #8
GazL
LQ Veteran
 
Registered: May 2008
Posts: 6,882

Rep: Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988
Well, for the siconv stuff as it all appears to be text files, shouldn't that really be stored somewhere under /usr/share, rather than /usr/lib(64 or otherwise)?

I've never really liked the idea of programs dumping stuff other than their shared libraries under /usr/lib[64]/<programname>. It just feels untidy to me.

And don't even get me started on all the crap under /usr/lib/rpm!


These aren't really Slackware's fault though. It's upstream being untidy. In a lot of the cases the stuff that gets dumped into /usr/lib/<programname> looks like it actually belongs somewhere in /usr/share, /usr/libexec and on odd occasions even /etc.


I commend you for caring about this jong357. It's something that gets under my skin too.
 
Old 02-21-2010, 09:13 AM   #9
sahko
Senior Member
 
Registered: Sep 2008
Distribution: Slackware
Posts: 1,041

Rep: Reputation: Disabled
Quote:
Originally Posted by jong357 View Post
Nothing... What does that have to do with anything. /usr/lib should be completely empty on a 64bit system unless they are 32bit libs.

As I've already said....

"As a matter of correctness, this should be taken care of...."
Did you ask Pat?
 
Old 02-21-2010, 11:00 AM   #10
Petri Kaukasoina
Senior Member
 
Registered: Mar 2007
Posts: 1,731

Rep: Reputation: 1411Reputation: 1411Reputation: 1411Reputation: 1411Reputation: 1411Reputation: 1411Reputation: 1411Reputation: 1411Reputation: 1411Reputation: 1411
Quote:
Originally Posted by GazL View Post
I've never really liked the idea of programs dumping stuff other than their shared libraries under /usr/lib[64]/<programname>.
This is even worse: samba dumps crap directly to /usr/lib[64] with names like /usr/lib64/fr.msg containing text files (translations for SWAT). The name of the file or the directory give no clue to what program the file is for. All programs could install French translations to the same filename.
 
Old 02-21-2010, 06:47 PM   #11
jong357
Senior Member
 
Registered: May 2003
Location: Columbus, OH
Distribution: DIYSlackware
Posts: 1,914

Original Poster
Rep: Reputation: 52
Quote:
Originally Posted by sahko View Post
Did you ask Pat?
I stopped doing that a long time ago because I typically never got a response. Seems the "official" Slackware forums are no different. The PyQT bug still exists and so does $ARCHTYPE in liloconf.....

Don't mean to be a dick but this is insanely sloppy.... How long does it take for a team (ie - plural) to fix things when one person manages to keep things tidy on his own bootstrapped system (ie - me)?

Oh yea... This is why I quit using Slackware. I remember now. You guys are still running a shadow on 13.0 that's literally from 2003 or before. I've been using SHA512 for eons now but Slackware can't even use anything but MD5...

It's just really absurd. I'll shut up and take my toys home now. It's just really a shame when people don't pay attention to detail. Bothers me really bad for some reason... Bothers me even more when I take the time to report bugs but they go unfixed for months.

Last edited by jong357; 02-21-2010 at 06:49 PM.
 
Old 02-21-2010, 06:59 PM   #12
jong357
Senior Member
 
Registered: May 2003
Location: Columbus, OH
Distribution: DIYSlackware
Posts: 1,914

Original Poster
Rep: Reputation: 52
Quote:
Originally Posted by GazL View Post
Well, for the siconv stuff as it all appears to be text files, shouldn't that really be stored somewhere under /usr/share, rather than /usr/lib(64 or otherwise)?

These aren't really Slackware's fault though. It's upstream being untidy.
Yes, but it is Pat and company that need to be held accountable for fixing this stuff and not pushing out the same upstream garbage to the end users. Hey.... That's called making and maintaining a distro. Joerg Schilling has his head so far up his arse that things like this will never be "fixed" upstream.

So instead of complaining about something having to be in /etc/default, why not change it like I did above? Problem solved. Now you have a nice little /etc/cdrecord.conf file....

I dunno.

For that matter, I'm still curious as to how the kernel-headers package is made along with cxxlibs.... It's a mystery I guess. For all I know, they come from a fedora rpm and are just repackaged in tgz format...

Last edited by jong357; 02-21-2010 at 07:04 PM.
 
Old 02-22-2010, 06:22 AM   #13
GazL
LQ Veteran
 
Registered: May 2008
Posts: 6,882

Rep: Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988
Quote:
Originally Posted by jong357 View Post
Yes, but it is Pat and company that need to be held accountable for fixing this stuff and not pushing out the same upstream garbage to the end users. Hey.... That's called making and maintaining a distro.
Yes, I take your point jong, and as I said above, I also find this stuff frustrating, however, the opposite extreme of changing too much leads to things like the debian SSL fiasco, so care is needed.

Slackware has always been conservative about the changes it makes to what upstream provides. The best you can do is send in a patch and hope to convince Pat to agree to use it. And yes, it's very frustrating when you don't get a response. If you don't get satisfaction then you either have to live with it, make the changes locally, or move on to something else.

So far I do the first two of those. Occasionally, frustration gets the better of me and I feel like doing the third, but short of 'rolling my own' Slackware is still the best match for what I'm looking for, and no distro is perfect.

Last edited by GazL; 02-22-2010 at 06:27 AM.
 
Old 02-24-2010, 02:41 PM   #14
Lufbery
Senior Member
 
Registered: Aug 2006
Location: Harrisburg, PA
Distribution: Slackware 64 14.2
Posts: 1,180
Blog Entries: 29

Rep: Reputation: 135Reputation: 135
Jong,

I hate to see this thread derail into grumpiness and frustration because I think there's a valid point or two here. Naturally, there's nothing stopping any of us from rebuilding the package using your patch -- even if Pat and the team do not. So, thanks for the contribution.

FWIW, src2pkg has some functions for correcting the location of files. You might want to look into that utility a bit.

By the way, I've been reading your modification of the DIY Linux reference build. I'm learning a lot. Thank you.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Opera10 64bit Java fix for SBO slackbuild. GazL Slackware 9 10-13-2009 08:38 AM
cdrtools-2.00.3 art3mis Linux - Software 1 12-22-2004 09:43 AM
2.6.9 and cdrtools, is it fixed? stelmed Slackware 7 11-05-2004 09:59 AM
cdrtools? crapper Slackware 2 09-30-2004 09:33 AM
cdrtools installation Bon Bon Red Hat 12 04-01-2004 04:25 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 11:03 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration