From jeroen@dekkers.cx Mon Mar 18 16:23:19 2002
Do you want to know the way Debian works? You fix it yourself and tell the patch to the maintainer about it. The maintainer intergrates it and all users get the fix. As soon as the Debian maintainer intergrates the patch it's available in Debian unstable. Debian maintainers must forward patches upstream, so the upstream developers
Sorry, but I am forced to repeat me:
The Debian Bug list is badly managed (at least for cdrecord) and it does not help to keep cdrecord bug-free. Tehy never removed remarks for bugs that never exists but are a result of missunderstood or unread documentation.
If you patch is right it won't be difficult to convince the maintainer if the maintainer isn't an asshole!!
So you just made a statement anbout the GNU make maintainer. I send him a description for an algorithm that fiyes the problem and would allow somebody who knows the program to create a fix in less than 3 hours.
It works perfect if you use a limited set of features.=20
It doesn't work if you try to use a feature which it does *NOT* have.
Again: we are talking about dcumented features!
before they were able to reproduce a problem using my smake.
Is the thing which doesn't work in GNU make a documented feature?
Y E S
What is wrong with this way and why do you constantly tell people to do things that won't work in real world?=20
If it works for you, then stop complaining about the bugs in GNU make. I only tell that if you have problems with GNU make you should fix them yourself. If you want to use another piece of software, happily do so. Just don't promote non-free software on this list which goes about free software.
You again start to reverse facts:
I stopped complaining about GNU make 3 years ago and don't take GNUmake for serious anymore.
YOU are the person who asked me to use the buggy GNU make and thus forced me to explain why I don't like this.
What do you mean with "multi-platform environment"? According to my experience developping glibc parts the build system works fine. If you have suggestions to improve it you're always welcome of course.
READ the schily makefile documentation!
I am talking about features of this system (e.g. untar the archive and then fire up a 'make' on all supported platforms simultaneously whithout the need to di more than just call 'make'):
What's difficult to understand about this?
YOu have difficulties to understand, so you need to answer this question yourself.
Well the authors of GDB restrict me because it is the only debugger avail=
able=20
on Linux and because I cannot do the things I expect a debugger to do.
Don't redefine restrict.
I don't do it sorry but you sesm to fail to understand the meaning of the word. GDB _is_ a restricted debugger because it has a limited set of features that restrict me when I try to use it.
If you have a system when there isn't a limit on the path and PATH_MAX doesn't exist, realpath() doesn't work correctly then. You've no way to be sure the buffer doesn't overflow, it's even a security risk.
If PATH_MAX does not exist, then pathconf() must work to return the needed value.
Many GNU users have this wrong assumption, this is why I am more and more angry with the people who wrote documentation tha makes users believe untrue things about the GNU programs...
I hope you aren't in the group of people who just named and can give an example of the POSIX incompatible thing when using tar with the --posix option.
All information you need is in the star distribution. I am sorry, but I am at CeBIT and it takes too much time to constantly repeat facts known and described since (at least) 1993....
Jörg
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) If you don't have iso-8859-1 schilling@fokus.gmd.de (work) chars I am J"org Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix
FOKUS at CeBIT Hall 11, A14 - BerliOS at CeBIT Hall 11 D11 (Future Market)
Meet me at CeBIT in Hall 11 D11 on the BerliOS booth - www.berlios.de