LinuxQuestions.org - cdrtools.SlackBuild 64bit

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - cdrtools.SlackBuild 64bit (https://www.linuxquestions.org/questions/slackware-14/cdrtools-slackbuild-64bit-781677/)

jong357

01-12-2010 06:06 AM

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}

voyciz

01-12-2010 07:46 AM

Err...do you realize that Slackware64 ships with cdrtools and the build script is included with the source?

~sHyLoCk~

01-12-2010 07:53 AM

Check /ap

jong357

01-12-2010 08:24 AM

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 (Post 3823558)

....to make it multilib compliant.

Besides, I totally quoted the official SlackBuild comment in my code box....

jong357

02-21-2010 07:33 AM

Any word on this Eric, Robby or Pat?

As a matter of correctness, this should be taken care of....

forum1793

02-21-2010 08:00 AM

Just out of curiosity, what are you running that MUST be 32 bit that requires or interacts with the cdrtool programs?

jong357

02-21-2010 08:23 AM

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

GazL	02-21-2010 08:59 AM

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.

sahko

02-21-2010 09:13 AM

Quote:

Originally Posted by jong357 (Post 3871401)

Did you ask Pat?

Petri Kaukasoina

02-21-2010 11:00 AM

Quote:

Originally Posted by GazL (Post 3871436)

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.

jong357

02-21-2010 06:47 PM

Quote:

Originally Posted by sahko (Post 3871456)

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.

jong357

02-21-2010 06:59 PM

Quote:

Originally Posted by GazL (Post 3871436)

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

GazL	02-22-2010 06:22 AM

Quote:

Originally Posted by jong357 (Post 3871951)

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.

Lufbery

02-24-2010 02:41 PM

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.

All times are GMT -5. The time now is 09:23 PM.