* Joseph Carter (knghtbrd@bluecherry.net) wrote: > On Thu, Jun 13, 2002 at 10:03:04PM -0400, Eric Dorland wrote: > > > I think you have let one too many people who have taken leave of their > > > senses get to you with these packages already. I have yet to see a > > > package which ran with 1.5 that does not run with 1.6 (and I've been > > > looking for them!) > > > > Well as a mathematics professor I had once said, "Examples do not > > constitute a proof". Have you asked the automake developers about > > this? No offense, but they would know better then you. > > I've read the changelogs. The GNU people are nothing if not careful about > changelogging their changes. Hmmmm, they've still made no real guarantees in their documentation that it will work in all cases (or even 99% of the cases). But if you test everything that depends on automake1.5 and it all works with automake1.6, or is fixed to work, I see no point in keeping it around. > > > > I get to choose being able to RTFM _OR_ being able to compile .... just > > > about every package out there. Not a good choice, please make the > > > packages not conflict in this manner. Especially it would be good if you > > > could make both sets of docs installable at the same time. I'd much > > > rather have automake 1.4's docs than automake 1.4, since that will tell me > > > what I need to make sure my scripts are compatible backward and > > > forward. > > > > I am not happy with this solution either. But the automake upstream > > packages it this way, ie their info files are not versioned. I sent a > > mail to their mailing list about this issue, but received no > > response. I'm always reluctant to really hack up upstream's way of > > doing things. My knowledge of info is not incredible, but I believe > > doing this sanely is non-trivial. > > Perhaps whoever did it for autoconf can help? That might have been aj I > think. That would be nice. But I need something maintainable... not something that i need to fiddle with for hours after there's a new release of automake. > > Well I always planned to provide alternatives on 'automake', I just > > thought it was much more important to get these packages in and sane, > > and then add that. > > Then why hold off on doing this? The packages are basically not very > useful to software developers until that's done. That's a ridiculous statement. They are still very useful for people who need it to build their packages. So users have to do "automake-1.6" instead of "automake". They can tough it out for a few days. And if your programs depend on automake 1.6, they should call it by automake-1.6, or more compatibility issues could bite them in the ass. And besides, I wanted to add this feature to all the automake packages at once to ease upgrading. I'm "holding off" for a good reason. > > I don't think anyone is saying that fixing this would be a bad > > thing. They're just wary of a lot of breakage, which I think is > > smart. Caution is the better part of valor. > > I don't disagree. I believe 1.4 should be what you get when you ask for > automake by default - this isn't a question of compatibility as that 1.6 > is still new software and people may prefer to stick with what they know > works until they know that the new version also works. The new version > needs to be readily available for the more adventurous to work on, though. Well I absolutely agree. > The problem is that your current packages are simply not useful for ever > making automake1.6 not an experimental thing, and I think they should be > fixed. I can't help immediately with the info stuff, but if nobody else > can either, I'll figure it out. They're not *broken*. They don't do everything I want them to do, but they're completely useful. They're going to get there, just keep your pants on. It's not going to be useful to anyone if I don't get it into main, so that's priority one. I'll see what I can do about making "perfect" packages tomorrow. -- Eric Dorland <dorland@lords.com> ICQ: #61138586, Jabber: hooty@jabber.com 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ ------END GEEK CODE BLOCK------
Attachment:
pgp7OUFfggukI.pgp
Description: PGP signature