Binary Packages / Port Builds Conflict Explained

[nanotek]

I keep hearing the generic: don't mix ports with packages. Could someone please provide a concise yet clear explanation of what the conflict is and, if possible, how to successfully make the two coexist without complications (and without developing your own local repository)?

Is it simply that a) if you install ports with non-default build options, this may create dependencies that will be installed, which otherwise would not be installed with binary packages and b) performing pkg upgrade will then either only upgrade installed packages or try to upgrade programs installed from ports which may have non-default build options and the inverse [*]?

Whether a or b, couldn't you just portmaster -a -x <stock pkg install program 1> <stock pkg install program 2> <stock pkg install program 3> <etc> to update ports with existing custom build configurations before performing pkg upgrade <file containing list of stock pkg installs> (or whatever the pkg command is to update individual ports (i.e. not everything])?

[*] portmaster -a will either only upgrade installed ports or try to upgrade programs installed from binary packages.

 

[sossego]

Building from ports should be done::

1. If the user wants a specific configuration not provided by the default package installation pkgng.
2. If the user has non standard architecture.
3. If the user is porting to another architecture.
4. Et al.

Using pkgng is easier when::

1. The system is limited on memory, disk space, or CPU capability- speed and/or type.
2. The user wants a quickly installed package.
3. Et al

My view on this.

 

[nanotek]

Building from ports should be done::

1. If the user wants a specific configuration not provided by the default package installation pkgng.
2. If the user has non standard architecture.
3. If the user is porting to another architecture.
4. Et al.

Using pkgng is easier when::

1. The system is limited on memory, disk space, or CPU capability- speed and/or type.
2. The user wants a quickly installed package.
3. Et al

My view on this.

Although not really answering my question(s), I do appreciate your opinion(s). Mine are similar, I think that ports should only be used when neccessary, viz. when non-default build options are needed. About half the time I want a specific configuration that mandates building from ports, I should be able to install the remaining applications from packages to save resources.

 

[scottro]

I think (going by my own experience) that generally, the worst that will happen is a port will fail to build because a package may have installed something that needs fixing. For example, I installed, on FreeBSD-10-RC-something, some package related to X by using pkgng. Among other dependencies, it installed graphics/dri. There was an issue with dri, explained in UPDATING. Due to this issue, when I later tried to install x11-servers/xorg-server from ports, it failed due to the dri issue. So, it cost me a few minutes applying the fix mentioned in UPDATING. A complete beginner might not have realized that the build failed due to dri, and might not have know to check /usr/ports/UPDATING, so that might have been a problem, but with a little experience, even a relative newcomer can probably figure out where to start troubleshooting a failed install.

I've frequently mixed ports and packages, and that was the worst thing that's ever happened to me. A more typical problem, which is really not what I'd consider major, is that using a package might install an older version of say, perl, and then, when installing something from ports, it might have to remove and reinstall perl with the newer version.

Therefore, I would say that generally you can use packages, and then, when you do have to use a port, you might run into issues, but said issues are usually minor inconveniences. Obviously, all this is at your own risk. It may be worth testing on a virtual machine first, especially if the machine you plan to do this with is important to you. That being said, I can't think of reading about any instances of someone completely breaking their machine by using ports and packages, but if it does, then there will no doubt be those who will say, We warned you. (And if you just use one or the other, and your machine breaks, there will be other versions of, You should have done it this way, so I wouldn't worry too much about it.)

 

[Deleted member 9563]

In my amateurish experience over the last couple of years, packages have not been available for many important programs. For me they have generally just been very many hours of wasted time from which I learnt very little. Of course some packages may be available now that weren't when I was trying, but I'm not going to go back and forth to figure all that out. I'm not a professional with all day to spend on this. That said, it is common for ports to not compile successfully. Yes, there are ways to deal with that, but they are often time consuming and beyond the non-professional user. In that case, if a package is available it will often solve the problem. In any case, I don't think it is possible to build a complete system for desktop use using packages only, though it may be possible for server use. Just my 2¢.

 

[nanotek]

I think (going by my own experience) that generally, the worst that will happen is a port will fail to build because a package may have installed something that needs fixing. For example, I installed, on FreeBSD-10-RC-something, some package related to X by using pkgng. Among other dependencies, it installed graphics/dri. There was an issue with dri, explained in UPDATING. Due to this issue, when I later tried to install x11-servers/xorg-server from ports, it failed due to the dri issue. So, it cost me a few minutes applying the fix mentioned in UPDATING. A complete beginner might not have realized that the build failed due to dri, and might not have know to check /usr/ports/UPDATING, so that might have been a problem, but with a little experience, even a relative newcomer can probably figure out where to start troubleshooting a failed install.

Sounds like what I expected regarding the don't mix ports with packages dogma. And, in your example, it is a problem that would occur if using ports exclusively but failing to acknowledge UPDATING.

I've frequently mixed ports and packages, and that was the worst thing that's ever happened to me. A more typical problem, which is really not what I'd consider major, is that using a package might install an older version of say, perl, and then, when installing something from ports, it might have to remove and reinstall perl with the newer version.

Therefore, I would say that generally you can use packages, and then, when you do have to use a port, you might run into issues, but said issues are usually minor inconveniences. Obviously, all this is at your own risk. It may be worth testing on a virtual machine first, especially if the machine you plan to do this with is important to you. That being said, I can't think of reading about any instances of someone completely breaking their machine by using ports and packages, but if it does, then there will no doubt be those who will say, We warned you. (And if you just use one or the other, and your machine breaks, there will be other versions of, You should have done it this way, so I wouldn't worry too much about it.)

I will experiment. I already use packages for build dependencies, extending their use to all programs that don't require custom builds is efficient system administration.

In my amateurish experience over the last couple of years, packages have not been available for many important programs.

I've never experienced this, but my FreeBSD experience in general is very limited.

For me they have generally just been very many hours of wasted time from which I learnt very little.

If you care to elaborate, I would be interested in learning how using packages resulted in wasted time. I can understand little was learnt by installing programs, but I find this true regardless of which method is used (i.e. portmaster www/nginx = pkg install nginx in terms of education).

Of course some packages may be available now that weren't when I was trying, but I'm not going to go back and forth to figure all that out. I'm not a professional with all day to spend on this. That said, it is common for ports to not compile successfully. Yes, there are ways to deal with that, but they are often time consuming and beyond the non-professional user. In that case, if a package is available it will often solve the problem. In any case, I don't think it is possible to build a complete system for desktop use using packages only, though it may be possible for server use. Just my 2¢.

I tend to agree with you; I, too, am not a professional and prefer to accomplish tasks efficiently. I consider use of packages, where possible, to be efficient system administration.

 

[Deleted member 9563]

In my amateurish experience over the last couple of years, packages have not been available for many important programs.

I've never experienced this, but my FreeBSD experience in general is very limited.

I guess I had jumped in just after there was a security breach and all packages were wiped from the repository. Only a few were available. It took me a week of frustration before I found that out! I thought there was something I didn't understand - something wrong with me. I wish this had been explained somewhere like in the handbook, but of course that's not the place for news even though it was made a mockery of in this case. I think the packages are mostly done now, but I'm not sure if they are all there yet.

For me they have generally just been very many hours of wasted time from which I learnt very little.

If you care to elaborate, I would be interested in learning how using packages resulted in wasted time. I can understand little was learnt by installing programs, but I find this true regardless of which method is used (i.e. portmaster www/nginx = pkg install nginx in terms of education).

I spent some days trying to get a version of *office because I absolutely had to have one of them. I couldn't figure out why they weren't in the repositories since they were listed everywhere. I found a couple of packages elsewhere on the net which didn't work with my existing system. It was nightmare. So I tried a ports, but they were seemingly broken. Apparently they really were, and there was no fix yet - but it took me days to ascertain that. I had to wait. Again I believe the real problem was my timing. It's not a perfect world - I know. I think the whole repository was in a mess yet others, who already had working desktop systems, or were running servers, were not having a difficult time; just those that were installing new systems. I also installed other packages at that time which were broken in the context of my system. I can't remember exactly, I think Zotero, Bluefish, and some PDF programs. I suppose I did learn something about what to watch out for. In other words, don't take _anything_ for granted.

In any case, I finally got a working system by starting with ports. This last year I'm onto a second install using FreeBSD 9.2-RELEASE, but on two machines this time. Perhaps packages would be as trouble free, or even better, but I am sticking to what worked for me because it is functional and I don't want to spend more time than I need getting things to work. Once bitten - twice shy. I am already spending orders of magnitude more time than most people are willing to do - just because of my self inflicted ethics, and quirky tastes.

PS: And don't forget that there are proprietary programs needed for the web which only come as ports because of licensing.