Re: cdrkit 1.1.10 fails to locate libcap
Mark Rosenstand <rosenstand@gmail.com> wrote:
> > Given the fact that there have been many new features added to cdrtools since
> > the time some people created the "fork",
>
> I don't use a distribution, but the fact is that when the big distros
> adopt something, it is likely to get used by a lot of people, including
> e.g. CD burning GUI front-end application developers.
Let us look at the bigger distributions:
Solaris
*BSD
Gentoo
Slackware
SuSE
Arch Linux
and many others distribute the original software.
RedHat seems to be a hostile distribution as there are extremely hostile
mails from RedHat - maybe we need to sue RedHat to let them learn that
they cannot distribute software that is in conflict with GPL and Copyright law.
On March 6th 2009 at CeBIT in the Sun booth, Debian made a binding commitment
to distribute the original cdrtools as soon as possible and there is already a
binary packet waiting at Debian since more than half a year. Let us see whether
a binding commitment from Debian is something substancial....
Ubuntu is just a Debian downstream....
In case you don't know, authors of frontends for cdrtools know about the > 100
bugs in the fork and thus prefer to use the original software.
> > Well, cdrtools uses a standard leading edge build system. The fact that is
> > has extreme similarities to the build system created by David Korn that
> > is written on top of a new make utility "nmake" but uses the same ideas
> > of just having a list of source files in the leaf makefiles verifies that
> > it uses the right basic ideas. In contrary to other build systems, it
> > grants out of the box compilation on 30+ platforms. It may be that you
> > are not flexible enough to lean new software and that you just not notice that
> > many of the OSS packages that use different build systems just do not compile
> > even on major platforms like Solaris without manually changing significant
> > parts.
>
> No doubt autotools and even cmake have their weaknesses too, but they
> are much more widely used (at least in the projects I'm interested in),
> so I can invest time in learning them.
It is interesting that you even mention cmake which creates worse results
than you get from using the so called "autotools".
> Another fact is that cdrtools on Linux cannot even be built in parallel
> on the world's most widely used make(1) implementation, GNU make.
All software that uses the Schily Makefilesystem of course can be made in
parallel. Just try e.g. "dmake" from Sun.... it is even available for free for
Linux x86.
There may be a problem with GNU make. GNU make is full of bugs that are not
fixed. I did e.g. file a bug report for a coneptional bug to the GNU make
maintainers in 1998 and they accepted the bug and told me that it will take a
bit longer to get fixed. Now 12 years have passed and nothing was fixed. The
bug I am talking about here, creates warning messages for include files that
make people believe that there is a bug in the schily makefilesystem although
the bug is in GNU make.
GNU make does not yet seem to be ready for being used as a parallel make tool.
Note that GNU make is still to dumb to separate the output of commands run
in parallel. This makes it impossible to see the relation between the error
messages and the source files the messages are created for. I have also been
told by other people that GNU make ignores some dependencies if in parallel
mode and thus may fail. Given the fact that GNU make before version 3.81 even
ignores dependencies in non-parallel mode (and thus cannot be used for
cdrtools), it seems that there is just another hidden bug that was not fixed
correctly.
GNU make claims to be portable to many platforms but if you try to verify this
claim, you will find that GNU make compiles on all these platforms but on many
platforms, there is no resulting usable GNU make binary. GNU make e.g. does not
work correclty on all platforms that use <CR><NL> as line separator or that use
the backslash as path name separator. This is a result of the incorrectly
implemented parser for Makefiles in GNU make. GNU make does not work for me in a
useful way on OpenVMS, MS-WIN, BeOS, Haiku, OS/2. This is why I use "smake"
as the reference make implementation as smake is working correctly on all
known platforms and as smake is cleanly written and thus may easily be fixed in
case there is a problem.
BTW: in case you don't know, smake is even ~ 5 years older than GNU make.
The next thing I am going to implement in smake is support for parallel makes
and you can be sure that it will work correctly ;-)
> We are getting very much off-topic, so excuse me for not replying
> further at least on this mailing list.
I don't beleive that we are off topic as what you believe seems to be a common
missunderstanding for many people and thus it makes sense to correct you in
public.
> Again, I do not use any other software that uses your build system, so
> also packaging smake would be a waste of time for me.
See above, the problem with GNU make is that it is full of problems....
GNU make can only be used a last resort and because of the problems in GNU make,
smake automatically compiles even if there is no make at all on a specific
platform.
Note that some problems you see with smake on Linux are not smake problems.
If you e.g. have bash-3.x installed as /bin/sh, the compilation will not stop
on errors as bash-3.x is not POSIX compliant. If you in such a case first
get the whole schily source consolidation from:
ftp://ftp.berlios.de/pub/schily/
install the binaries and then call ./.clean and make a new compile run, the
resulting smake will use /bin/bosh or /opt/schily/bin/bosh with is a working
Bourne Shell that does not have the named bash bug.
> > Just in case you don't know: I was the fisrt person who tried to sue companies
> > for violating the GPL and while doing this, I learned that most of the GPL
> > claims cannot be enforced in court. The CDDL is a license that is more liberal
> > and just includes those claims that are enforcable in court.
>
> IANAL so I can't comment on this.
Well, I was in contact to many lawyers and I still am in contact to lawyers.
I mentioned this as there is a lot of missinformation on the GPL in the net.
Jörg
--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Reply to: