Martin: You are wrong. It is frankly NOT my responsibility to figure out why the problem occurred. As a user of the package, is only my responsibility to report failure, that is it. For your convenience, I even used FinkCommander,
I did not say it was your reponsibility, we have maintainers for that. But in criticizing what I did, you did *not* act as a user (I can show you dozens of mails from users appreciating what I am doing). You put on the condescending user-despising developer act that you used to bash Max for.
which included relevant system details. Manually removing is a workaround, not a fix. I am not 'forgetting the time factor'. My main point here is that this was a bug in the package, and you acted like it was not (in multiple
This is not true. Why do you think I wrote to fink-devel about this (and about half a dozen other problems with the new gnome packages, some of them more severe). Of course there is a bug when a package does not build.
emails.) I figured out why it failed on my own because apparently, noone else cared. Why should I have to? Where is the bug tracker item on this?
I figured out why it failed and wrote about it to gnome-core, and I published a workaround. It is not my duty to fix the package. There is another time factor at work: My time. I try to use it in the best way. Finding and testing a real fix takes at least 10 to 100 times more time than finding the error plus a workaround (10 to 20 minutes vs several hours or sometimes weeks). If I try to find a fix, then it is for more serious errors like the new interesting brain disease that libtool shows when trying to compile gtkhtml3. Or for fixing my own packages like the non-functioning python-wrapper in vtk. I assume that if the maintainer of a package is aware of a problem including its cause, he will act, and another bug report is not necessary. But he will act in his own time.
If you get so excited about this workaround instead of a real fix, you might want to go over the Fink FAQ. I would say that at least half of its entries are due to behavior that could be classified as bugs, like fink always wanting to install xfree86, although the user already has Apple's X11. Oh, I see you mention this below.
Yes, if something is a bug, make sure you point that out. You can include the workaround. If you really think these issues don't cause people to leave fink, you haven't been around long enough or talked to enough users. We see them on IRC all the time (usually in #opendarwin, after having rm -rf /sw)
And then they are happy with darwinports? LOL.
And dude Martin, get this in your skull - fink-gnome-core is **NOT** A FORUM. I DO NOT HAVE TO READ IT. fink-gnome-
I wrote to fink-devel that I think this was a serious mistake. It *is* a sourceforge forum whose archives you can read. We are in a special situation here where one person released over a hundred new package versions, and it is obvious that he alone is not capable of keeping up with all the bug reports. Again the time factor: After such an event there is a period of a few days where everybody is trying this out, and if you drive them away after the first bug report without helping, you loose them. After a week or so, all the bug reports can be sifted through and real fixes can be searched for, but in the first few days you have to do with workarounds.
core is a 'group maintainer' which was made world-readable so people wouldn't be blocked out of helping to maintain it. I STRONGLY object to creation of new fink forums i have to search every time i need to report a problem. I absolutely refuse to do so. I thought this group maintainer stuff was a bad idea in the first place, this is yet another reason why. Now WE ALL get to maintain it! Wohoo! Thats the same as no maintainer at all, if i have to read
To a certain degree we all have been maintaining everything since Panther was released. Time factor again. This will level out after a while.
fink-gnome-core! Anything you 'announce' on fink-gnome-core is being 'announced' only to fellow maintainers of the fink-gnome packages. Since it is not a forum, the maintainers of fink-gnome-core are responsible for replying to each email personally. Should i now read Ben Reed's email before reporting KDE bugs? no.
But if there is a bug database (dunno if there is, I have no time to follow this KDE thing yet), I suppose you are advised to look whether your bug has been reported before. Most bug databases ask users to do this.
And this is NOT truly a 'recent thing with big updates', there are packages which have been in unstable for weeks which do not upgrade. This is not specific to gnome. I believe the system-xfree86 upgrade from 10.2 is still broken, in fact it is in the FAQ. Noone cares. Half our perl modules don't upgrade.
You are right, but I think you are wrong to say that nobody cares. There are just priorities. Take the case of qt3, since you mentioned its maintainer. Since the release of Panther, it has had two problems:
- The bindist version does not run on Panther, it would be very easy to fix this, and I have been ranting about this several times, but the 2 or 3 people who have access to the bindist have more important things to do. Hence the dozenfold repeated advice to the poor users: Build it from sources. It is a bug that this should be necessary, the fix is easy, people do care, but it is not fixed (Reminds me of startx and friends in Apple's X11: It is broken, they know about it, fix is easy, people complain all the time, yet it is not fixed. Priorities... Together with giving a workaround or what is actually a real fix, I usually tell people to file a bug report with Apple.)
- People who compile it from sources all get the same error, because one has to remove the old version first before compiling the new one (sound familiar?). I spent hours on hunting this down, maintainer knows about it, he spent time to fix it, but it is still not fixed. Do you want him to stop working on KDE/Qt-Mac and concentrate on fixing a bug that has a known workaround?
Another case: The <freetype/freetype.h> thing: The cause is known, it would be possible to fix every package concerned, but it would take months to first identify these packages and then to find a fix for each one of them. Nobody is going to do this. We can even be lucky if someone finds the time to write a FAQ entry with the workaround.
-- Martin
------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
