Dear Chris, all,
On 06.09.2012, at 17:54, Chris Zubrzycki wrote:
> I don't mind at all. A possible change would be to use update-alternatives to manage the symlinks. This way if others want a default of an earlier version they can easily have it.
I thought about that. Its main advantage would be that it does not require those -core packages. But I ultimately decided against it, because it would require changing all packages that bdep on some version of automake simultaneously.
On the other hand, with my proposed strategy, we can gradually change those packages.
Of course, I still would like to get all packages changed as quickly as possible to use the "proper" versioned automake strategy.
Now, if people prefer the update-alternatives approach, I could also implement this, and try to adapt all packages that use some version of automake to build using the new scheme... but I cannot possibly test all those changes completely (testing whether they build: yes. Testing whether they work correctly: No).
> Sent from my iPhone
> On Sep 5, 2012, at 23:20, Max Horn <max@...> wrote:
>> Dear Chris, (CC: fink-core),
>> after some discussion with dmacks, I'd like to propose a somewhat bigger change to the automake packages. Namely, I want to make it possible to install them (or rather, most of their content) in parallel. The end result should be that the user can have all of
>> installed simultaneously (same for aclocal). This is rather important for developers who create build system using automake (e.g. myself ;). Because those then are tied to a specific major version of automake. The fact that fink constantly switches automake versions when building stuff then causes lots of needless pain...
>> And on the long term, the goal is to get completely rid of all this switching between automakeN packages...
>> To achieve this all while retaining compatibility, I came up with the following plan (which I already implemented, but have not yet committed):
>> Each of the three automakeX.Y package get a %N-core splitoff, which contains only versioned files. These -core splitoffs can all be installed simultaneously. For example, automake1.12-core contains:
>> /sw/share/aclocal-1.12/ (with content)
>> While automake1.12 mostly retains symlinks:
>> /sw/bin/aclocal -> /sw/bin/aclocal-1.12
>> /sw/bin/automake -> /sw/bin/automake-1.12
>> /sw/share/man/man1/aclocal.1 -> /sw/share/man/man1/aclocal-1.12.1
>> /sw/share/man/man1/automake.1 -> /sw/share/man/man1/automake-1.12.1
>> /sw/share/aclocal/ (placeholder)
>> Right now I also put the texinfo files, unversioned, into this, as it didn't seem worth the effort version it:
>> With this setup, both of my goals are attained: Developers can have all three (and more in the future) automake-X.Y binaries in parallel (via the -core splitoffs). And packages which bdep on automakeX.Y can usually be converted to a bdep on automakeX.Y-core (thus avoiding the need to switch automakeX.Y packages) by changing
>> autoreconf -fi
>> invocations to
>> AUTOMAKE=automake-X.Y ACLOCAL=aclocal-X.Y autoreconf -fi
>> Finally, the automakeX.Y packages themselves would behave like they currently do, meaning we can incrementally transition packages to the new setup, and don't have to do it all at once (although I think it would be good to try to convert most .info files to this approach ASAP, and ideally also upgrading as many of them as possible to to automake1.12 -- but that's a secondary objective at most).
>> All in all, I can't think of any drawbacks of this approach. If you don't mind, I'd like to commit this as soon as possible.