Here's an updated, more fleshed out version of upgrading everything c+ + at once to gcc4/abi2
from #fink
02:52 < cirdan> will you help me on my upgrade plan? :-)
02:52 < cirdan> i need a feature or to in fink for it to be possible
02:52 < cirdan> smalish stuff
02:52 < dmacks> Tell me about the features.
02:52 < lisppaste> dmacks pasted "xdrawchem on 10.3" at http:// paste.lisp.org/display/7574
02:53 < dmacks> TheSin: also, boshcp took almost half an hour on my dual 1.25GHz G4
02:53 < cirdan> ok, user has fink on 10.3, fink distro set to 10.3 (or 10.2*)
02:54 < cirdan> they install tiger
02:54 < cirdan> fink will not let them build any new packages until they do a `fink dist-upgrade`
02:54 < cirdan> (except for fink itself)
02:55 < cirdan> basically if installed osx != current distro in fink.conf fink will yell
02:55 < dmacks> That's something I've been meaning to implement for a while actually:)
02:56 < cirdan> user does fink dist-upgrade, fink displays lots of warnings and faq URLs, as too what will happen
02:56 < cirdan> and no timeout, no is default
02:56 < cirdan> if they dont wanna upgrade, they can continue to use the 10.3 apt-get servers and stuff
02:57 < cirdan> user decides to fink dist-upgrade
02:57 < cirdan> fink sees current os as 10.4, so does selfupdate and activates 10.4-trans tree
02:58 < cirdan> this tree is empty, except for placeholder .info files for *every* g++* using package, very important. same versions as {un}stable, just very high rev
02:59 < cirdan> there is a new essential package, 10.4-clean-c++ (or something) that depends on each one of those placeholder packages, to force the user along
03:00 < cirdan> the 10.4-clean-c++ has a post install that changes the tree to 10.4 and does another selfupdate
03:00 < dmacks> "every g++ using package" is just libs, or also everything that depends on them?
03:01 < cirdan> 10.4 tree uses gcc4 mostly, and g++4 only (abi=2)
03:01 < cirdan> everything, nothing can stray
03:01 < dmacks> (good)
03:01 < cirdan> we can't have libs, and the users will yell very loud if the app is there and no libs :-)
03:01 < cirdan> hehe
03:01 < cirdan> uhg
03:01 < cirdan> ugh
03:02 < cirdan> now we'll have 10.4/c++, with the non-working c++ packages (for developers)
03:02 < cirdan> and as the c++ crap builds with g++4 and it's deps are met, they go back into {un}stable
03:03 < cirdan> we won't force an upgrade, but we will make it clear that they cannot build w/o upgrading
03:03 < dmacks> Your 10.4-clean-c++ approach is flawed: you lose track of what c++ stuff the user had, so when he gets to the actual 10.4 tree, he'll have dummies for *every* c++-using package.
03:03 -!- MacDome [EMAIL PROTECTED] has quit [Read error: 110 (Connection timed out)]
03:03 < dmacks> ...not just the ones he had before starting.
03:03 < cirdan> ah
03:03 < cirdan> yes
03:04 < cirdan> ok, c++-fix conflicts with every c++ package < rev in 10.4 trans
03:04 < cirdan> but actuaclly an update-all will install all the new packages
03:04 < dmacks> Also a maintenance nightmare. Since we'll still be supporting 10.3, we'd have to update that 10.4-clean-c++ every time we add a new version or package that uses c++ to the 10.3 tree.
03:04 < cirdan> hmm
03:05 < dmacks> When one installs a package that "conflicts" with others, those others get nuked. Again, you've lost track of what the user had.
03:05 < cirdan> dmacks: only if there is also a replaces
03:05 < cirdan> otherwise it refuses to install
03:06 < cirdan> you are right, i didnt think about updates in 10.3..
03:06 < cirdan> we might be able to do it programmaticlly
03:07 < cirdan> scan all .info files, fill in a skeleton .info with updated version and a revision of like 401
03:07 < cirdan> since by policy any c++ package is declared with the gxx flag
03:08 < cirdan> hell, with some time and effort fink dist-upgrade could create it's own 10.4-trans tree
03:09 < cirdan> (scan all local .info files and all)
03:12 < htodd_> dmacks: what did I do now?
03:12 -!- htodd_ is now known as htodd
03:20 xhrl [EMAIL PROTECTED] has joined #fink
03:21 < dmacks> cirdan: That scan/build-.info on-the-fly is probably the *only* way that could work.
03:22 < dmacks> htodd: I was looking at your term-readline-gnu-pm581 package, which contains a note "Should eventually [do something with it]" that's about a year old. Was wondering if that eventuality will come to pass.
03:23 asparagui [EMAIL PROTECTED] has joined #fink
03:23 < dmacks> (/me noticed it because the .deb no longer validates either)
03:25 -!- asparagui [EMAIL PROTECTED] has quit [Client Quit]
03:26 asparagui [EMAIL PROTECTED] has joined #fink
03:26 -!- asparagui [EMAIL PROTECTED] has quit [Client Quit]
03:26 asparagui [EMAIL PROTECTED] has joined #fink
03:26 < asparagui> ugh.
03:26 < asparagui> sorry.
03:26 < dmacks> heh
03:28 < cirdan> hmm
03:28 < asparagui> well, fyi: /server in ircle changes the currently active server and _not_ the currently selected one.
03:28 < cirdan> how hard do you think that would be, dmacks? does fink have the ability to do that? dumpinfo does have a lot of info...
03:28 < cirdan> actuaclly it seems fairly easy...
03:29 < cirdan> hmm
03:29 *cirdan* wonders
03:29 < cirdan> dmacks: so do you think it could be a viable plan?
03:30 < cirdan> given we have 9 days we could freeze new c++ versions in 10.3 for a few days after release (new -rev would be fine)
03:30 < dmacks> The idea could work; it's not concrete enough to implement I don't think. And we *really* have no time to just now start testing a new approach.
03:30 < dmacks> *think _yet_
03:30 < cirdan> we have no other approach
03:31 < dmacks> drm seems to have been doing *something* these past day or two, no?
03:31 < cirdan> i shot down drm's new idea earlier
03:31 < cirdan> can't work cleanly
03:31 < cirdan> was a good one though
03:31 -!- dreamind [EMAIL PROTECTED] has quit [Remote closed the connection]
03:31 < dmacks> You may have used a bunch of ammo, but the idea is still up there.
03:32 < dmacks> fink-0.24.4 with the changed SetCXX is already in the release queue.
03:32 < cirdan> as soon as the first c++ lib/app pair is updated, anything that links to it will break
03:33 < cirdan> dmacks: ok, my idea is less of a 10.4 upgrade, as it is an abi upgrade
03:33 < dmacks> Won't "anything that links to it" have a new version in the new tree?
03:34 < cirdan> no
03:34 < cirdan> his idea was foo needs bar, when they both build with gcc4, update them to abi2/g++4
03:35 < cirdan> but baz also needs bar, and baz[1-13] do not build with g++4
03:36 < dmacks> In the case {foo baz} need bar, wouldn't your "his idea" statement be modified for [the whole set]?
03:36 < cirdan> so everything is interlocked tightly
03:36 < cirdan> no, cause baz[0-13] all need intertwined deps on different sets of libs
03:37 < dmacks> So can only update [a whole self-consistent cluster]. We have lots of experience doing just that when moving stuff unstable- >stable.
03:37 < cirdan> and you'll never be able to upgrade anything more than a self-contained app/lib pair
03:38 < dmacks> (not "pair")
03:38 < cirdan> dmacks: nothing will build in the correct order, w/o tons of versioned deps that will be a moving target
03:39 < cirdan> and as soon as you sart the build process all hell breaks loose w/the other installed apps
03:39 < cirdan> esp. if something fails
03:39 < dmacks> Didn't drm already explain to you that things *will* build in the correct order if you do the versioned-deps correctly.
03:39 *cirdan* looks 3 lines up...yes
03:40 < dmacks> Installation failure at the "bottom" of a dependency pile is where things would get ugly yes.
03:40 < pogma> cirdan: For the moment, we have the transitional tree idea, the transitional tree will need populating, the "10.4" tree will have to wait
03:40 < pogma> cirdan: And the transitional tree will use g++-3.3 abi version = -1
03:40 < pogma> q.e.d.
03:41 < cirdan> pogma: for my plan only the clearing of g++ apps would need be done in -trans
03:42 < cirdan> we could immediatly go to the 10.4 tree
03:42 < pogma> cirdan: not going to happen
03:42 < cirdan> i just dread all of the sticky problems with long slow upgrades...
03:42 < cirdan> better to get the bleach out and clean the board :-)
03:44 < cirdan> i could prolly get the trees in line by release w/1 or to other ppl, its the new fink stuff that I prolly can't do that quick
(sorry for the raw paste, but I wanted everyone to see some of the drawbacks each plan has)
I sent this on the 20th, odd, it's not showing up...
-chris zubrzycki - -- PGP public key: http://homepage.mac.com/beren/publickey.txt ID: 0xA2ABC070 Fingerprint: 26B0 BA6B A409 FA83 42B3 1688 FBF9 8232 A2AB C070 ========================================================
ICBM Address: 39.795906N -75.056029W
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
