On Sun, May 19, 2002 at 02:50:09PM +0200, Eduard Bloch wrote: > Jeroen Dekkers wrote on Sun May 19, 2002 um 01:47:35PM: > > YOU are actually one of those problems, you are somebody who > > downgrades grave bugs to wishlist because the Hurd is unreleased. I > > So? The w32 guys may argument the same way. You think that Hurd is the > better POSIX OS, I think it is equivalent, but still having important > structural problems that need to be fixed. We are not asking you to make POSIX incompatible changes. > > don't need to write a FAQ about that, it's already documented that if > > a package doesn't build it's a grave bug. > > I refuse to thread arch-specific problems as RC bugs as long as this > arch is not to be released with. "Important" isn't RC. So why downgrading? > > Yeah we know the Hurd is an unreleased architecture and the bts > > doesn't understand that, that's why we file the bug as important > > instead of grave. But that doesn't mean that the bug is wishlist, it's > > Your opinion. If the upstream cares about portability and has an own > list of supported architectures, he should be involved! If a package > does not appear on the list of supported systems, you do not have any > right to request the "bug" to be fixed by Debian people. http://www.debian.org/Bugs/Developer#severities Where do you see something about architectures? It has nothing to do with them. http://www.debian.org/doc/developers-reference/ch-porting.en.html#s-source-nmu-when-porter FYI: The Hurd port is part of the unstable distribution. From the social contract article 2: "We will make the best system we can, so that free software will be widely distributed and used. We will feed back bug-fixes, improvements, user requests, etc. to the "upstream" authors of software included in our system." According to what I've learned with the NM process, I have the right to request you to apply the patch and forward it to upstream. If the bug isn't fixed, I've the right to do a NMU. It's just that you don't *want* to cooperate and thereby violate almost every policy or guidelines document Debian has. > End-of-discussion. I'm not a Debian developer but I know more about the Debian standards than you do. And then people tell me Debian GNU/Hurd should follow the Debian standards and procedures. How ironic. And then, you say that they are violating the standard, and they immediately want to stop discussing. And that's what I don't like about Debian too, it looks like people only use the standards to lart other people instead of looking about how to do it themself. And this is especially true for social contract. > > still a grave bug. This is all documented, no need for me to write it > > down another time. > > Where? Why do you not start discussions with pointing to such > "documents"? I do not read debian-hurd mailing list, and I cannot remember > any references of such docs on debian-devel. See above. > > And of course people reinvent the wheel. Do you know why? Because some > > people just don't want to cooperate to do it together all at once. > > Debian is based on cooperation. Yes, that's why I quit, because I somehow can't cooperate. I say why I can't cooperate and then other people can decide who/what the problem is. > > > What is the problem? Make it /lib/exec and it is FHS compliant *g*. > > > > The problem is that binaries from *BSD won't run on Debian *BSD and we > > have to change every GNU package and the GNU coding standards. > > Then modify the policy after having a consens. Unfortunately, this > action has to wait till Woody has been released because of the current > release strategy (I won't make any comments about it's pros/contras > here). But we can have a discussion. It's not that we need to moderate debian-devel during a freeze. People who are busy can simply ignore the discussion for that moment. > > If you look at portability and compatiblity, those 'linux people' are > > just as worse as Microsoft, the company they hate so much. The > > difference is just that they use free software and the biggest part of > > the GNU system. And I think that's a problem, because I want GNU/Hurd > > to be compatible and portable. > > You make a conclusion from few Debian-internal problems to the whole > Linux comunity - not a good point to start, you know... Uh, it's not like I have seen other things. My pthreads work is a very big example of this unportability and incompatiblity in the Linux community. > > > > compatible. Other than that, the only OS specific annex is for > > > > GNU/Linux. No BSD too. The FHS is just GNU/Linux, nothing more. Don't > > > > > > It does not mean GNU/Linux and only this duo. It may be your personal > > > interpretation, not the common one. > > > > Can you give me another OS which is compliant with the FHS? > > Same here. Sounds like an indirect proof without contrary facts. Some Linux people just wrote some facts down about their current system without looking at other systems and called is a standard for unix-like OSes. I have already given facts why I think that this was done this way. I think the GNU Coding Standards are written much more careful and are probably compatible with 4.3BSD (at least they should be compatible with BSD because that was what current practice at that time, GNU/Linux didn't exist yet). Jeroen Dekkers -- Jabber ID: jdekkers@jabber.org IRC ID: jeroen@openprojects GNU supporter - http://www.gnu.org
Attachment:
pgpSCDWqIDAgX.pgp
Description: PGP signature