On Mon, Jul 31, 2006 at 10:30:48AM -0600, Bob Proulx wrote: > Were you trying to use fakeroot on a Linux kernel or a different > kernel? It could very well be that fakeroot is Linux specific. But > it works fine for me. Yes, we're Linux-specific. And I admit it needs some work, e.g. the new *at() calls should be wrapped too, I guess (not sure)... > Of course your own software will always be more familiar to the person > who wrote it. And if you are producing your own distro then you might > have good reason for choosing a custom solution. But because fakeroot > has been around for a long time and seems not to have any reason not > to use it then I suggest sticking to using it if possible. If it has > issues then reporting them upstream would be good. It is better to > avoid needless feature and program forks when possible. It was more than 3 years ago... These were not some minor issues with fakeroot, we completely failed to get the slightest sign of making it work, but reading the docs it was clear that we'd need a completely different issue for solving the same problem (due to several other reasons as well, e.g. make the build process restartable from some checkpoints). If there's a bug, you can report it, you can fix it and send patches, and wait for this to get applied/fixed. But if you just believe that the whole approach is completely overcomplicated and messed up and you just hate it and think that it can solved much more simpler and you really do it in a few hours??? IIRC it's a Debian software, ain't it? Well, our experiences about Debian feedback is... well... yeah... khmmm... far from perfect, to be very very polite. Anyway, I just showed an alternative, then let everyone decide which one he prefers. I don't want to convince everyone to use "pretendroot", I just offered this as another choice. > Yes. But I consider all of those bugs. It can be draining but please > report those upstream as bugs. If everyone does that then it is > easier to peer pressure inexperienced maintainers into improving their > processes. We're trying to put up a distribution as good as we can, 2-3 people working on this. We have no resources to report and explain every small detail that we think could be done better. That's why we built up a very automated and very robust build system (so we don't even face those stupid "install -o root..." commands), and of course we report bugs that are trickier or those that other distros can benefit from. But not these minor ones. Just one example: there's a well known closed source browser named after a music style, with a shell script installer that used to have no DESTDIR support at all. I spent a half day sending DESTDIR patches to them and explaining them what a DESTDIR installation means, and then they sent back their version of the patch, where it turned out that they didn't get the clue, so I had to explain it them once again in even more details. But at least now it's officialy part of that browser. Hope you agree that we are simply unable to report these kinds of problems for every package. > Hmm... As I read that the unfortuante thing is that spec files for > your distribution are uniquely different from others. (Of course in > many ways that is already true for most distros for other reasons.) Yes it's true since we wanted to automatically convert our already existing compilation rules which are in a completely different syntax. But the whole project was dropped so it's not important at all, those spec files do not exist at all, except somewhere in my machine, if I haven't erased them yet. -- Egmont _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
