Re: cdrkit 1.1.10 fails to locate libcap
On Sun, 2010-01-03 at 15:04 +0100, Joerg Schilling wrote:
> Mark Rosenstand <rosenstand@gmail.com> wrote:
>
> > > Cdrkit is undistributable as it is in conflict with the GPL and the Copyright
> > > law. Cdrkit is unmaintained since May 6th 2007, so why do you ask for cdrkit?
> >
> > The 1.1.10 source package on ftp.debian.org is dated just over a month
> > ago, but yeah, it's unfortunate that it hasn't hit the upstream download
> > area yet. Latest stable release of cdrtools seems to be from 2004
> > though.
>
> The fact that somebody creates new "versions" does not proof that there is
> some kind of maintenance. During the last 2.5+ years, there was much less
> changes in the fork than in a very lazy week of development on cdrtools.
>
> There are still more than 100 well known bugs in the fork that do not get fixed.
> Given the fact that most of these bugs could be fixed in much less than one hour
> each, it is obvious that the people behind cdrkit do not care about users....
>
> Cdrkit users are on a dead end, there are no bug fixes and there is no
> development.
>
>
> > > I recommend you to use the original software from
> > > ftp://ftp.berlios.de/pub/cdrecord/alpha/
> >
> > I've been using cdrecord for years before cdrkit appeared, but with
> > cdrkit being what most Linux distros package these days, I just go with
> > the flow, as it means less work/headscratching for me in the long run.
>
> Well, you are a user and you could ask your Linux distributor why he
> distributes unmaintained software with legal problems instead of well
> maintained original software with no legal problems.
>
> 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.
> > I'm maintaining all packages myself, so the totally non-standard build
> > system in cdrtools is a big minus, especially since pretty much all the
> > default paths, permissions, and even ownership are different from what's
> > casual on Linux systems today. When you have over 1400 source packages
> > to maintain, automation is key. (Sorry, I don't use any of your other
> > software, so I can't justify the time it will take to automate it.)
>
> 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.
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.
Linux has a huge user base, this is usually the reason most things tend
to usually just work there. Personally I prefer the BSD's - in
particular NetBSD - to Linux because of its beautiful and elegant
design, but I use Linux out of convenience.
We are getting very much off-topic, so excuse me for not replying
further at least on this mailing list.
> And BTW: if you like automation, you should already know the advantages of
> the schily makefilesystem as you just need to call "smake". The other packages
> you may be talking about, force you to call "configure" manually and usually do
> not even compile unless you find out some magic parameters you need to add
> to the "configure" call in order to get a usefull autoconf result.
>
> It may be that you are a victim of the Stickholm syndrom and like what punishes
> you ;-)
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.
> > > There are no known problems with the original software and the original software
> > > includes many new features that are missing from the illegal fork.
> >
> > This is a valid point and if GPL'ed software fails, I will likely give
> > it a shot. I were turned off a bit with the whole cdrecord-ProDVD thing
> > and then the CDDL issues, but at least the former seems no longer an
> > issue, and e.g. BluRay writing is indeed a nice feature.
>
> There never was such an issue. There have been some hostile people who spread
> incorrect claims on my software in order to harm.
>
> 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.
Cheers,
Mark
Reply to: