# Why RELENG_8 /usr/src/etc is older than RELENG_8_2 /usr/src/etc



## cakersq (May 6, 2011)

I've been using FreeBSD for a long time.  I love my 8.2-STABLE servers (root on Raid-Z), but noticed something counter-intuitive.

If I install an 8.2-RELEASE, upgrade source tree in /usr/src using the RELENG_8 tag to 8.2-STABLE, and do a *mergemaster* the files in /usr/src/etc are OLDER (lower CSV revision/date) than the currently installed /etc files.

Why is this?

Given that RELENG_8 is supposed to be the most up-to-date of the STABLE branch, and RELENG_8_2 (release) is effectively a snapshot of RELENG_8, shouldn't RELENG_8 have newer or equal revisions?

Thanks.


----------



## wblock@ (May 6, 2011)

Yes, except that the source is really kept in Subversion.  So when a release is branched, there's an automated process that goes through and checks in all the files as new versions in CVS, even the ones that aren't really new.


----------



## gordon@ (May 6, 2011)

All that means is the files have not been changes since the branch operation. Imagine that the file is at 1.4.1.1 in the STABLE branch (RELENG_8). When cutting the new branch for the release, it will be called 1.4.1.1.1.1 on the RELEASE branch (RELENG_8_2). If no one makes any changes to the file, it will remain at 1.4.1.1 which is technically older than the release.


----------



## rhish (Jun 16, 2011)

*Same situation*

It's been a while since I've installed/updated FreeBSD. Most recently I did a fresh install after grabbing 8.2-bootonly off the ftp server. Installed. And then ran cvsup RELENG_8.

Same as the OP, I thought I was getting the most recent 8-STABLE files.

But then, when I go to rebuild world, kernel, et.al., and then run mergemaster, it has to stop at like every file in /etc (and others). It's stopping at each file because the dates are different, or revision number, whatever. The revision line is the problem on all of them.

I noticed, for all of them, the date is off by months. The explanations given thus far sort of make it seem like a non-issue. But, is it really a non-issue? What should I do about all the files? Do I update each file, it's hundreds of files. Or do I leave them as is?

It seems like the solutions provided would occur right after it branches, but should be resolved by the time we are all the way into 8_2? I don't remember this ever happening in the past. It just kind of doesn't feel clean. Having to make a change to every file after a fresh install and cvsup.

Is there a cleaner way of having the most up to date files, short of current, without having to do mergemaster and update so many files? Will this situation eventualy work itself out? Like suggested, once someone updates those files on the server or ..?

Okay, any and all help, advice is welcomed.


----------



## rhish (Jun 16, 2011)

p.s. Does this mean EVERYONE who is following 8-STABLE is updating ALL those files each time they *cvsup* and rebuild world? It really feels out of the ordinary when it's so many files. How is it like normal?

I spent hours thinking through what I was doing, it feels like I'm doing something wrong, or missing something simple. How is this the way thigns are and it's ok?


----------



## rhish (Jun 16, 2011)

p.s.s

The files I'm getting from cvsup.freebd.org when using tag=RELENG_8 are from 08/2009. While the files from my fresh install using 8.2 are 12/2010. A year and 4 months difference. It's got to be something else, something I'm doing wrong, or not seeing.

If I run *cvsup* using tag=RELENG_8 I should be getting the latest development of 8. So, whatever I get, the files should at least be the same date as 8.2-RELEASE (12/2010) or newer? Right?

If the files from 8.2-RELEASE are dated 12/2010 then the 8-SATABLE files should be 12/2010 or newer?

The ones I'm pulling down, today, 15 June 2011, are dated 2009.


----------



## SirDice (Jun 16, 2011)

rhish said:
			
		

> p.s. Does this mean EVERYONE who is following 8-stable is updating ALL those files each time they cvsup and rebuild world?


No, only when going from 8.2-RELEASE to 8.2-STABLE.

As for having to review every file in /etc/, read the mergemaster(8) manpage. There are some switches you can set that will do a lot automatically.


----------



## rhish (Jun 16, 2011)

SirDice said:
			
		

> read the mergemaster(8) manpage. There are some switches you can set that will do a lot automatically.



Ok, so that is the proper thing to do? I use the files from 2009, instead of the more recent 2011 files, to be up to date? Does this mean RELENG_8 hasn't been updated since 2009? Or does it get updated, yet "dated" 2009? Would it be more "up to date" to use RELENG_8_2?

I just want to update my system to whatever is the most recent stable development of FreeBSD 8, short of using -CURRENT. And, from what I'm gathering, that means using files from 2009? When there are releases way newer than that?

RELENG_8 should mean "newer" more recent, than any release in that line right?

I dont remember it being this backwards.....


----------



## SirDice (Jun 16, 2011)

The files that haven't been touched since 2009 are just that, files that haven't been touched since 2009. Why would anyone change a file if it's correct?

The only difference between -RELEASE and -STABLE is that most of these files have a different RCS tag at the top of the file. That's why the -RELEASE files are newer.

In any case, just run `# mergemaster -UFi`

As I said, you'll only run into this when going from -RELEASE to -STABLE. Once you are on -STABLE you won't have this problem.


----------



## rhish (Jun 16, 2011)

Would it be proper to do a *mergemaster -a*, which would leave them all in the temp directory? Then I have the choice of either moving them over myself, or leaving the newer files. What would be the proper thing to do? What I'm worried about are changes.

What if something has changed since 8.2-RELEASE. And so, RELENG_8 would be where the change would occur, right? If there has been any sort of change, to any one of those hundreds of files, since 8.2-RELEASE, then the change will be in RELENG_8.

Is there a way to just start out with an install of RELENG_8? Instead of having to install 8.2-RELEASE and update?


----------



## rhish (Jun 16, 2011)

Ok, posted my last reply before I saw your last reply. I'll try `mergemaster -UFi`

Is there a proper way of just starting from -STABLE? Instead of what I'm doing? For instance, if I have a new computer, and want to install FreeBSD, can I start with -STABLE? Instead of a -RELEASE? What should I use as my install source? I can do everything through my inet once I get booted, I would just need some help identifying where in the install I would indicate -STABLE instead of -RELEASE. If that makes sense?


----------



## SirDice (Jun 16, 2011)

rhish said:
			
		

> Is there a proper way of just starting from Stable?


Yes, you're doing it.


----------



## DutchDaemon (Jun 16, 2011)

@rhish, you have a PM about formatting and writing style. Read it before posting more.


----------



## wblock@ (Jun 16, 2011)

rhish said:
			
		

> Ok, posted my last reply before I saw your last reply. I'll try `mergemaster -UFi`



The "F" isn't necessary.



> Is there a proper way of just starting from -STABLE? Instead of what I'm doing? For instance, if I have a new computer, and want to install FreeBSD, can I start with -STABLE?



There are snapshots of more recent -STABLE installations on the FTP sites.  But it's not necessary.  Once a run of mergemaster with the -U option has been completed, it keeps track and you won't be asked about files that haven't changed the next time.  It also helps to set /etc/mergemaster.rc to ignore files that should not be updated.

Relevant articles:
Upgrading FreeBSD To -STABLE
Building FreeBSD World And Kernel: The Short Form


----------



## rhish (Jun 16, 2011)

wblock said:
			
		

> The "F" isn't necessary.
> 
> 
> 
> ...



I guess that is what I was more concerned with. i.e. whether or not this is proper, or a cheap fix. It would seem, from your post, this is the normal way of doing things, or, the proper way even. So, those people who are starting new FreeBSD systems, are running into the same issue. And the means of dealing with the issue, which you explained, is the appropriate way of solving the situation. And is normal. 

Now that I know things are this way, I can research and make sure I have everything right. 

Thanks for explaining.


----------

