Upgrade suggestion

[Gary Kline]

On Tue, Mar 27, 2007 at 03:59:54AM +0200, Danny Pansters wrote:
> On Tuesday 27 March 2007 01:40:40 Gary Kline wrote:
> > 	Hi Folks,
> >
> > 	Last night it struck me that one reason I constantly find new
> > 	ports to upgrade is that with ~17K ports, if you're running one
> > 	of the more common desktop managers and several popular apps,
> > 	there are going to be at least a dozen minor tweaks every day.
> > 	E.g.:going from foo-1.6.7_2  to foo-1.6.7_3.   I used to run
> > 	port[upgrade|manager] twice/week.  Was swamped; recently,
> > 	upgrading things daily.   Since a lot of the wm ports take
> >
> > 	> 24 hours to build/re-build, I'm pretty much wedged.   Thus
> 
> But you don't *have* to rebuild all the time. I'd wager to say that it's 
> foolish to do so. When you have, e.g. a nice open-office, compiled with, say, 
> the KDE option, there's no immediate need to update the beast if it happens 
> to be updated. Maybe if it's a security fix, but otherwise if the thing works 
> well for you, no need to update. Unless you want to of course. I do a massive 
> portupgrade every 1-2 months on my desktop and I don't feel I'm missing out 
> (and if I do I'll do that update earlier). And yes, usually there's a thing 
> or two that I have to fix manually. It will happen also if you 
> csup-through-cron every day. Perhaps more often. I think you're trying to 
> overdo whilst still trying to minimize build time (= stability shall we say) 
> and such. They're two conflicting goals. 


	Hi Dan

	My latest (of N:) thoughts/ideas was to do a custom i686 build 
	on my P2 and P3 boxes.  This on my 700-750MHz server, this one.
	Eventually I would have everything in package form and it would
	be simple to scp * around.  It would take months to get
	everything built with O3 (and gcc4.x), optimizing for speed by 
	doing [[intelligent]] loop-unrolling.  Last year I had my first 
	fatal panic in 11 years.  And I hadn't cross backup in days....
	<shudder>.  Some eu-daemon must have been looking out because a
	fellow I don't know/never met stopped over and did some network 
	magic, and got enough off my drive.  That panic was a good lesson
	because it impelled me to automate backups.  Stability is an end
	goal, but perfect stability is a mirage... .  Besides, the kind
	of stability I'm looking for is in the kernel, and BSD has as 
	stable a kernel as exists.

> 
> We have more than one port update tools (and they do somewhat different 
> things), that would complicate things a lot I think (what color is yer 
> bikeshed), and such a thing would probably need to be in the binary update 
> (Colin's) stuff too. 


	At least five years ago one listmember was complaining about the
	ports system and was advised to come up with his own.  He said he
	would and wouldn;'t be back until he was finished.  One of the 
	first things is, as I see it, is to define the problems ... and
	do so on a whiteboard or forum.  One tack that I would take 
	would be to have a  "freeze-frame" one every N days or weeks.
	Once the ports collection worked/built (or 95+% of it), put it
	out for folks to build or download in generic [i3][4][5][686].
	See if this works; then do it for the other architectures.  But 
	I'm sure it's not that clean cut.  The dependencies' dependencies
	had their own dependencies :-)  So... .

> 
> <contro>
> IMHO the sooner Google or in general the second IT/OSS boom fizzles out and 
> stops solliciting what in the end equals free labor the better. Just my 
> opinion. I don't trust them. They just want to have their fishing spot in 
> their own backyard just like MS and Sun and Apple and Novell and they want it 
> on the cheap. Once the "IP wars" go all out they are not going to give one 
> damn about the original author of a work that has become theirs or what (s)he 
> thinks or believes. 
> </versial>


	If I shared my *real* thoughts, somebody would  shoot me in the
	back! That said, I'm open to giving this a try.  We'll see if
	Google's ethics hold up.

> 
> I think if you want certain things in ports/packages to change or to have (yet 
> another) alternative management tool, the thing to do is to write it and PR 
> it. It will also give you the largest amount of control. And I bet you can do 
> it.
> 
> > 	Flames to /dev/null,guys; rational responses see-vous-play.
> >
> > 	gary
> >
> > 	....Still trying to learn French :-)
> 
> Meh. l'Amour et l'enfer are all you need to know. Oh, yeah, and fries of 
> course. That's s'il vous-plait (needs two ^'s on both i's IIRC). I also found 
> it useful to know where the Rue des Bons-Enfants was in Paris but you 
> probably don't. Very off-topic :)
> 
> > 	PS:  I hopefully will be upgrading//getting a faster used server
> > 	     to replace TAO.  Even if that resolves part of my upgrade
> > 	     problem, I think we can do lots better with maintaining
> > 	     current ports.
> 
> A week or so ago, you were asking about packages and if they might be offered 
> by port submitters. I think if submitters would use tinderbox to build 
> packages it may be much easier to get pkgs that are all from (somewhat or 
> even exactly) the same pristine build environment. That's one idea I thought 
> of (some port maintainers and most committers use it). I wonder if it might 
> be too much to ask of our submitters/maintainers though.


	What do you mean by "build environment"?  There can be hundreds.
	I'd go for vanilla (i386), then the rest of the Intel arch.
	Leave CFLAGS (or other build flags) to the makefiles.  

	gary



> 
> Dan
> 

-- 
  Gary Kline  kline at thought.org   www.thought.org  Public Service Unix