Hi Scott, * Scott James Remnant ([EMAIL PROTECTED]) wrote: > I notice that with a recent change to automake-1.9 you have adjusted the > priorities so that 1.9 is the default, instead of 1.4. However this > still does not solve many of the problems people have had in Ubuntu, so > we've proposed a specification to transition the archive to the newest > Automake and drop 1.4. > > https://wiki.ubuntu.com/AutomakeTransition
Glad to see some one else interested in these issues besides me for a change :) > As the Debian maintainer, we'd really appreciate your opinion on this; > especially as there are several options listed which we have yet to > choose between. Looking at the wiki page, you have some good ideas there. From Debian's perspective I think option 3 is a non-starter. Even if we banish all automake 1.4 using packages from the distro there will still be old code out there that will want it. But it is fairly deprecated garbage at this point, so its use should be discouraged. Here's what I believe would make the most sense: 1. Remove the automake and automaken provides from automake1.4 and take it out of the alternatives infrastructure (alternatively leave the alternatives but still removing the provides, with automake1.4 providing the lowest alternative value). Make clear in the package description and whatnot that automake 1.4 is deprecated and should only be used in highly special circumstances. 2. Start shipping an automake package again that would track the latest upstream version of automake (or be a dummy package that depended on the latest version) and give it the highest alternative priority. This will give most users the latest version (and hence have a better automake experience), while still allowing packages to depend on other versions. 3. Leave the alternatives system in place for >= 1.6 versions of automake, to give people the ability to say "No, I want my system to be version 1.X of automake, until I say otherwise" For this to happen in Debian anything depending on automake would need to be fixed. As of yesterday, 79 packages are still build depending on "automake" by my reckoning. Most of these are likely trivial to fix. I'm not sure I could get approval to do this from the release managers since the freeze cycle for etch is about to begin, but I'm willing to try. I'm sure I'd need to run this the lists to make sure I'm not talking crazy talk, but mostly I've had support for various automake related cleanups in the past. Your Option 4 proposal to have a wrapper shell is interesting as well. I'm not sure how feasible it will be though. Just because an automake script declares itself to need 1.7 or later, doesn't really mean it might not break with 1.9. But it would be pretty interesting if we could figure something like that out. > Obviously any work we do will have the patches for all packages > (including depending ones) supplied both to you and to the respective > maintainers, so that there is a minimum amount of work to get it into > Debian. -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] 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------
signature.asc
Description: Digital signature
