Why did FreeBSD decide to make ports management more/so difficult?

[Chris_H]

Greetings,

I've been recently forced to do a long overdue update/upgrade on a RELENG_8 box (8.2-STABLE --> 8.4-STABLE). Why did I wait so long? Well, I'm heavily involved in many projects, and for some I am the lead developer. This leaves me precious little time, so everything must be on a schedule. Turns out, "pointyhat" doesn't have a schedule for barfing on my ARCH (amd64). So, every time I went to perform the update/upgrade, pointyhat was barfing on my architecture -- meaning; the src tree wasn't going to build|upgrade properly/correctly on my box either. So, now you know.
To further aggravate matters this also meant using a new port maintenance system:
(cv)sup --> Subversion-1.7 --> Subversion-1.8 -- don't think that wasn't a pain.

Anyway, I solicited some advice on the @stable list prior to "taking the plunge", and @wblock (thanks Warren! ) was kind enough to chime in, and suggest portmaster(8) to aid in the endeavor. One of the reasons I chose his suggestion, was that it didn't require anything the system didn't already offer. So I went ahead and deleted /usr/src, /usr/ports and all the directories that (cv)sup used to maintain ports. Then I proceeded using Subversion && and portmaster to begin the process. I initially had a couple of gotchas with Subversion, but that was simply because my initial checkout was Subversion-1.7, and my update was with Subversion-1.8. Anyway, nothing was broken || or corrupted. So I moved on to portmaster(8). portmaster -a barfed a couple of times. I attempted to reconcile things, but, while the portmaster(8) man(1) page is large, it leaves much to be desired, at least where users new to Portmaster are concerned. For example, the -s option is available, but not specifically described. The --index option indicates using an INDEX-[7-9] style INDEX, which led me to believe it would use my local - already-created INDEX file -- thereby using MY current INDEX, which describes MY system's version of the ports tree. But I was wrong, and it went and clobbered my INDEX, by downloading a more recent one. So now my system' out-of-sync.

So why not just svn update? Because I'm still trying to reconcile the tree I have, with what I have installed. Now I have to start the entire process all over. It appears I should have used the --no-index-fetch option. But I wasn't sure if that covered the INDEX-[7-9] style INDEXes. I have already read: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports.html several times. But, sadly, there isn't anything on INDEX. man INDEX() provides nothing either. So, it appears that this update/upgrade will possibly take ~Month to complete.

Sorry if this simply looks like a <rant>. But I've been on BSD since the late '70s, and at no time has it ever been such a pain to do something so important, and something that should otherwise be a routine a task. Something is gravely wrong with the current system && and the decision to change things that needn't have been changed so radically.

Thank you for all your time, and consideration.

--chris

 

[sossego]

If you follow the mailing lists, you will see that many ports are still being set to Clang. Some major ports had vulnerabilities that needed to be fixed. Simultaneous updating of ports will always be a hassle. You're better off dropping to console/terminal mode and updating the basics first.

Somewhere around two months ago, I decided to try updating the source /usr/src/ on a PowerMac G4. I know it is not the exact same thing but a similar event happened. There's a lot of work and few people working on it. Your input - and keep it positive - could help improve some ports.

 

[Chris_H]

Greetings, and thank you for your reply.

Not sure where clang fits in here. I wouldn't wish it on my worst enemy. In fact, I have the following in my src.conf(5) file:

WITHOUT_CLANG=true

Please understand, I mean no disrespect by this. Just saying.

As to having waited so long. I had no choice, and this wasn't the first time I was forced to wait a long time to update/upgrade. This is just the worst experience in nearly 30yrs. 30 years on [size=-1][Free?][/size]BSD that I've had updating/upgrading, and it didn't need to be that way.

FWIW I'm on 9 lists, not-the-least-of-which is @stable.

Anyway, thank you again for the reply.

--chris

 

[sossego]

I've no trouble with clang when building ports. Have you tried setting

 WITH_GCC= $GCC_VERSION

on individual ports and let those that can build with clang remain as such?

 

[Chris_H]

Greetings @sossego, and thanks for the reply.

No I haven't. But, to tell you the truth, I'm not convinced that Clang is the answer to anything that isn't already available on the system. I rarely run into any problem that is GCC related. So I'm not sure why "changing horses in mid-stream" should suddenly be the answer to anything.

Best wishes.

--chris

 

[wblock@]

I don't understand the concern about the index file. It is only a reference to the ports tree. It is not related to the ports that you have installed.

Also, the question that is this thread's title starts from a conclusion, and I think that conclusion is mistaken. Ports have not become harder to manage.

 

[Chris_H]

I don't understand the concern about the index file. It is only a reference to the ports tree. It is not related to the ports that you have installed.

Also, the question that is this thread's title starts from a conclusion, and I think that conclusion is mistaken. Ports have not become harder to manage.

Greetings @wblock, and thank you very much for your reply.

See. That's exactly what I mean; man INDEX offers nothing. It would be my understanding that make INDEX makes an INDEX based on the contents of my ports tree. What good is downloading an INDEX from another tree that isn't the same version as mine? Perhaps the downloaded INDEX has ports/versions that my tree does not. What am I missing?

Thanks again, @wblock for taking the time to respond.

--chris

 

[Chris_H]

Also, the question that is this thread's title starts from a conclusion, and I think that conclusion is mistaken. Ports have not become harder to manage.

No offense, but I think that that is a matter of perception -- from my perception/experience, things have become harder. But I understand that from yours, they have not.

--chris

 

[wblock@]

ports(7) would be the place to look, but I don't know if it has any information about the index files. The Porter's Handbook may have more.

In the old days, rebuilding the index file was common and took forever. But if you have updated your ports tree, why not just get the index file from the same server? That's the current method. The file may be a little out of date, but usually not seriously. Upgrading FreeBSD Ports attempts to cover the simplest complete method to updating ports.

 

[wblock@]

No offense, but I think that that is a matter of perception -- from my perception/experience, things have become harder. But I understand that from yours, they have not.

But leaving a statement like that unchallenged is essentially agreeing with it, and I don't agree with it. Ports today are easier to manage than they were in the past. Problems like ending up with two ports of different versions seeming to be installed just don't happen any more. We don't have to spend half an hour rebuilding the index files after every update of the ports tree, or install programs that can rebuild it quickly.

Sure, sometimes people have trouble with ports. Most of the time, it is not due to a specific problem with the ports system. Sometimes it's a bug, sometimes a hardware problem, sometimes a misconception problem. It hasn't yet been anything unsolvable.

 

[Chris_H]

But leaving a statement like that unchallenged is essentially agreeing with it, and I don't agree with it. Ports today are easier to manage than they were in the past. Problems like ending up with two ports of different versions seeming to be installed just don't happen any more. We don't have to spend half an hour rebuilding the index files after every update of the ports tree, or install programs that can rebuild it quickly.

Fair enough. Seems as tho we agree -- It's all a matter of perception.

We don't have to spend half an hour rebuilding the index files after every update of the ports tree...

Of course not, we're not all running 386, 486, or p90's anymore.

Sure, sometimes people have trouble with ports. Most of the time, it is not due to a specific problem with the ports system. Sometimes it's a bug, sometimes a hardware problem, sometimes a misconception problem. It hasn't yet been anything unsolvable.

"specific problem with the ports system"

Here, I'm inclined to strongly disagree. It is my contention, that the requirement to drop the previous "standard" of maintaining source, and ports via (cv)sup, was unnecessary, and hence; a "specific problem with the ports system". Understand, I mean no offense by this. But I can find at least five other options that would have overcome the so-called "shortcomings" where CVS was concerned, and allow the FreeBSD base users, and developers to carry on with out hardly any notice. In all fairness to the developers; they would have been initially hit harder. But then, again, they were anyway. In fact, the introduction/requirement of Subversion introduced a multitude of issues -- server synchronization, incompatibility of options/versions, the ability to have it readily available in base/install. Licensing issues...

Anyway, that just covers the few things off the top of my head. It doesn't even touch the TCO (Total Cost of Ownership), and the additional overhead to those who's business/job is directly affected by the required change(s).

Again, please understand; I mean no disrespect to you, or your opinion. In fact, I am extremely grateful for all the help you have provided -- to both me, and that of FreeBSD, and it's base. I'm just saying, that's all.

Best wishes.

--chris

 

[wblock@]

I feel that the CVS retirement actually should have come earlier. And it could have been done better. Before CVS ended for ports, I was pushing for a replacement for csup(1). Eventually we got net/svnup, which is at least a functional replacement. And of course portsnap(8) was available.

But as far as using and managing ports, svn is easier than csup. No supfile, for a start.