On Wed 28 May 2003 12:45, Joerg Schilling wrote:
> From [EMAIL PROTECTED] Wed May 28 11:06:54 2003
>
> >> >[EMAIL PROTECTED] alpha]# uname -a
> >> >Linux alfonz.agenda.si 2.4.19 #1 pon avg 12 14:49:02 CEST
> >> > 2002 alpha unknown
> >> >
> >> >
> >> >cdrtools were compiled on this system using RPM. The spec
> >> > file is pretty
> >>
> >>                                    ^^^^^^^
> >>                                    ???????
> >>
> >> What should this be? As RPM is no standard, there of course is
> >> no RPM for the cdrtrools source package. Looks loke you are
> >> using an inofficial and mofified to be broken thing. Where did
> >> you get this from?
> >
> >I get cdrtools sources from
> > ftp://ftp.berlios.de/pub/cdrecord/alpha/ and then I use MY OWN
> > SPEC file to build MY OWN RPM package.
>
> Sounds strange! Why should one hack something around a working
> packet?

Why should one question whatever someone else does in their own time 
on their own system?

Incidentally, my guess at the answer is dependencies. If you install 
cdrecord this way then you can install an RPM for a frontend after 
it and RPM will have noticed cdrecord being installed, so it knows 
that it's available and you get a nicely working dependency system.

> >The SPEC file I use DOESN'T apply any patches and it DOESN'T run
> > any scripts to change the source code. It simply runs
> > 'configure' (which - in case of cdrtools - does nothing) and
> > then it runs 'make'. If all this goes through without errors,
> > it runs 'make install' and then packages all the relevant file
> > into my RPM package.
> >
> >Where is the problem!?
>
> Your broken make system.
>
> Just compile the source the correct way (by simply calling "make"
> after you did upack the tar archive) and it will work as
> intended.
>
> Proof:

<snip>

> Conclusion: your RPM stuff is useless (even more counter
> productive) and should not be used if you are interested in
> correct binaries.

Yes, not having the build system in the printed header is really 
going to cause cdrecord to malfunction. It works for him, doesn't 
it? Then what's the problem?

Sure, you have every right to not offer support for anything that 
isn't compiled and installed exactly in accordance with the docs. 
If you want to prohibit people doing things in a different way you 
should put it in the license. As long as it's not in the license, I 
think it's pretty arrogant to believe you have the right to tell 
people what to do with their computers.

Lourens
-- 
GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to