# Is it possible to make pkg "do the right thing(tm)"?



## Chris_H (Nov 6, 2014)

...or, yet another reason to hate pkg(8). 
OK I _really_ struggle with the new and, unimproved pkg(8) version. But I digress.
To the point; I've just installed 11-CURRENT on bare metal, and have built/installed world/kernel. I now want to install a minimal desktop. I'll be using this install as a base for future installs, via dump(8), and restore(8). I have *no* interest in pkg(8), or using "official" packages. This is *my* server, and I want to use *my* options, for the ports I install. Seems reasonable, doesn't it? 
So. I `cd /usr/ports/x11/xorg-minimal`, and `make` (note; I could have issued `cd /usr/ports/x11/xorg-minimal; make install clean`). But experience tells me that the process doesn't always end, as hoped for -- read on...
Well. Since this is a fresh install, this process takes a good long while, as there are many dependencies yet to fulfill (llvm, cmake,...). But it finally starts with the meat of the process, and happily dies within Mesa (or dri):

```
gmake  all-am
gmake[6]: Entering directory '/usr/ports/graphics/dri/work/Mesa-10.3.2/src/mesa/
drivers/dri/common/xmlpool'
cd ../../../../../.. && gmake  am--refresh
cd ../../../../../.. && gmake  am--refresh
gmake[6]: Nothing to be done for 'all-am'.
gmake[6]: Leaving directory '/usr/ports/graphics/dri/work/Mesa-10.3.2/src/mesa/d
rivers/dri/common/xmlpool'
gmake[5]: Leaving directory '/usr/ports/graphics/dri/work/Mesa-10.3.2/src/mesa/d
rivers/dri/common/xmlpool'
gmake[5]: Entering directory '/usr/ports/graphics/dri/work/Mesa-10.3.2/src/loade
r'
cd ../.. && gmake  am--refresh
cd ../.. && gmake  am--refresh
  CC  libloader_la-loader.lo
  CC  libloader_la-pci_id_driver_map.lo
  CC  libloader_la-xmlconfig.lo
In file included from ../../src/mesa/drivers/dri/common/xmlconfig.c:36:
../../src/mesa/main/imports.h:263:12: fatal error: 'xmmintrin.h' file not found
#  include <xmmintrin.h>
  ^
1 error generated.
Makefile:589: recipe for target 'libloader_la-xmlconfig.lo' failed
gmake[5]: *** [libloader_la-xmlconfig.lo] Error 1
gmake[5]: Leaving directory '/usr/ports/graphics/dri/work/Mesa-10.3.2/src/loader
```
I should have known better. As this was also a problem, some 3 and ½ weeks ago, on a RELENG_9 install. 
So. What am I to do? If I go by way of pkg(8) it will happily insist on installing some 20 other "official" packages, that do *not* have the choices I picked, for _my_ install.
Any thoughts, or suggestions, on how I might resolve this issue?
Sure. File a pr(1), and wait for the developer to fix the problem.
or
Sure. Figure out what went wrong. Create a svn(1) diff(1) that fixes it, and submit a pr(1) with the patch(1) 
While those were perfectly ligitimate answers/solutions. I'd like to avoid those routes, if possible. I need to stay gainfully employed, and waiting for an answer, is usually not an option.

Thank you for all your time, and consideration.

--Chris


----------



## talsamon (Nov 6, 2014)

xmmintrin.h is in /usr/local/lib/compilername/... What says `echo $PATH`?


----------



## SirDice (Nov 6, 2014)

Chris_H said:


> I've just installed 11-CURRENT on bare metal,


Keep in mind that 11-CURRENT is an unsupported version.

Topics about unsupported FreeBSD versions


----------



## Juanitou (Nov 6, 2014)

Sorry if I’m being obtuse, but how your problem is related to pkg(8)?


----------



## jrm@ (Nov 6, 2014)

If you're going to build your own packages, consider using ports-mgmt/poudriere-devel.  If you have more than one core it will try to build ports in parallel when possible and it will do the building in a jail.  While it sounds like poudriere won't fix this build issue, in general, with a clean build environment, you can avoid some errors.

ADDED: Here's a nice blog post that can help anyone interested in poudriere.

Also, blaming pkg here doesn't make sense to me.  Build errors like this have more to do with the specific port. As for your complaint about not liking the default options, this is a tough problem.  Think about the number of combinations of packages that would need to built even with a small number of options.  I have heard that package flavours and sub packages might be on the way.  This might make using the default packages more palatable for you.


----------



## Chris_H (Nov 6, 2014)

SirDice said:


> Keep in mind that 11-CURRENT is an unsupported version.
> 
> Topics about unsupported FreeBSD versions


Indeed. 11 _is_ [largely] considered an unsupported version. But we're not talking about 11 here. We're talking about _ports_, and if anyone wants to stay ahead of CVE's, and if anyone is using pkg(8) with the FreeBSD repos, they will be using the most recent versions from the svn(1) repositoriy. No? 
So. Just to clarify; I'm likely drawing from the same ports tree that someone on RELENG_9, or RELENG_10 is also drawing fom. 

Thanks for your reply, SirDice.

--Chris


----------



## Chris_H (Nov 6, 2014)

Juanitou said:


> Sorry if I’m being obtuse, but how your problem is related to pkg(8)?


Not obtuse at all. I was wondering (as also stated in the OP) if it were/might be possible to simply get pkg(8) to install Mesa, or Dri. *Without* insisting on installing all it's dependencies. So that *I* can still maintain *my* options for their (the dependencies) install(s).
Hopefully that makes more sense to you. 

--Chris


----------



## SirDice (Nov 6, 2014)

Chris_H said:


> Ieeeeeeendeed. 11 _is_ [largely] considered an unsupported version. But we're not talking about 11 here. We're talking about _ports_, and if anyone wants to stay ahead of CVE's, and if anyone is using pkg(8) with the FreeBSD repos, they will be using the most recent versions from the svn(1) repositoriy. No?


No. FreeBSD -CURRENT isn't what you think it is. It's the development version. As in bleeding edge, things breaking, things not working, etc. This includes building ports on -CURRENT.

Stick to a -STABLE if you want the latest bug fixes and features.


----------



## Chris_H (Nov 6, 2014)

talsamon said:


> xmmintrin.h is in "/usr/local/lib/compilername/..". What says `echo $PATH` ?


Thank you for the reply, talsamon.
`echo $PATH` won't get it here. I initiated the build from the /usr/ports/x11/xorg-minimal directory. So `echo $PATH` will only dump the $PATH reflected in my current $ENV, which always also includes $CWD/$PWD. _Aparently_, the file in question, was not found where it was expected. There are a lot of relative directry changes. Which are not uncommon. One of them may not have been quite right -- one too many ../. Or, perhaps not enough ../. Or, perhaps the file in question, wasn't included in the source, at all (forgotten).

Anyway. Thanks for taking the time to respond, talsamon.

--Chris


----------



## Chris_H (Nov 6, 2014)

SirDice said:


> No. FreeBSD -CURRENT isn't what you think it is. It's the development version. As in bleeding edge, things breaking, things not working, etc. This includes building ports on -CURRENT.
> 
> Stick to a -STABLE if you want the latest bug fixes and features.


OH sure. I understand. But I _know_ in this case. That I'm dealing with the same issue, when performing this build/install on RELENG_9 (9.3-STABLE). Because 3.5 weeks ago. I did the same thing on a fresh 9.3 install, and the same problem arose, on the same port (xorg-minimal), and with the same dependency (Mesa / dri). So while I fully appreciate what you're saying. I can positively attest, that in _this_ case, the situation is the same; whether -CURRENT | -STABLE. 

Thanks for taking the time to reply, SirDice.

--Chris


----------



## Juanitou (Nov 6, 2014)

Chris_H said:


> Not obtuse at all. I was wondering (as also stated in the OP) if it were/might be possible to simply get pkg(8) to install Mesa, or Dri. *Without* insisting on installing all it's dependencies. So that *I* can still maintain *my* options for their (the dependencies) install(s).
> Hopefully that makes more sense to you.
> 
> --Chris


Well, jrm explained it (again, as similar questions are often asked in this forum). I think that pretending that pkg(8) is not “doing the right thing” when the problem is a bug in a port is misleading for new users and does not benefit the FreeBSD community. Please understand my post in this regard.

In general, I still don’t understand why this “packages does not conform to my desired options” appears so often as an issue. I guess that configurable binary packages are common in other free OSs? Maybe because they benefit from larger infrastructures or better technologies? I’ve never used GNU/Linux or other… Anyway, I hope FreeBSD will provide them soon!

*EDIT:* Ah, I read again your message and I see that the problem is more complex: install a package but do not reinstall its customised dependencies, sorry…


----------



## Chris_H (Nov 6, 2014)

Well. Closer examination indicates the the failure is _indeed_ the lack of xmmintrin.h.
It doesn't exist where it was intended to be found. Nor anwhere else in the source's tar(1) ball. I'll poke around in other releases of ports/graphics/dri, or other incarnations of Mesa, and see if I can find the elusive file.

Thanks for all of your thoughtful replies.

--Chris


----------



## jrm@ (Nov 6, 2014)

`% pkg which /usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd10.0/4.8.3/include/xmmintrin.h`

```
/usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd10.0/4.8.3/include/xmmintrin.h was installed by package gcc-4.8.3_2
```


----------



## Chris_H (Nov 6, 2014)

jrm said:


> If you're going to build your own packages, consider using ports-mgmt/poudriere-devel.  If you have more than one core it will try to build ports in parallel when possible and it will do the building in a jail.  While it sounds like poudriere won't fix this build issue, in general, with a clean build environment, you can avoid some errors.


Greetings, jrm, and thank you for your reply.
Unfortunately, ports-mgmt/poudriere-devel will be of no value in this type of situation. If the port fails when built from the ports tree. It will certainly fail when built from within a Poudriere chroot(8). I think it also worth mentioning, that pkg(8) could also build a package for me, with my chosen options. By way of `cd /usr/ports/x11/xorg-minimal && make package` or by going to the dependent files, and initiating a `make config` prior to issuing the `make package` in the /usr/ports/x11/xorg-minimal directory. But again, in a failed build, all of these tasty treats, are irrelevant (moot).


			
				jrm said:
			
		

> ADDED: Here's a nice blog post that can help anyone interested in poudriere.
> 
> Also, blaming pkg here doesn't make sense to me.  Build errors like this have more to do with the specific port. As for your complaint about not liking the default options, this is a tough problem. Think about the number of combinations of packages that would need to built even with a small number of options. I have heard that package flavours and sub packages might be on the way. This might make using the default packages more palatable for you.


Not so. pkg(8) _is_ the problem. It has nothing to do with the myriad of possible options available, and pkg(8) being able to keep up with them. The problem(s) is that pkg(8) is *in*flexible, and *mandatory*. UNlike it's predecessor pkg(7). FreeBSD was the shining star where Operating Systems were concerned. In that FreeBSD was the OS of _choices_, where as Linux was more w/o without choices. You simply `yum`, `deb`, `rpm`, or whatever the distro's package manager was, all your applications. _Sure_ you could get the srpms, or whatever their source package(s) were, and go that route. But even then, the choices were, by comparison, far fewer than those available to *BSD users. This is all changing. FreeBSD appears to be going by way of parroting Linux, in some sort of effort to become a Desktop OS of choice. A bad decision, IMHO. PC-BSD is the intended use for that sort of thing. pkg(8) has caused _administrators_ an _incredible_ amount of grief -- some, even their jobs. All for reasons far to great to effectively articulate here. But I *do* intend to address this in a lengthy post on the lists.

Thanks again, jrm, for taking the time to respond.

--Chris


----------



## Chris_H (Nov 6, 2014)

jrm said:


> `% pkg which /usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd10.0/4.8.3/include/xmmintrin.h`
> 
> ```
> /usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd10.0/4.8.3/include/xmmintrin.h was installed by package gcc-4.8.3_2
> ```


*Thank you*, jrm, for taking the time to share that with me!
*Greatly* appreciated.

All the best.

--Chris


----------



## Chris_H (Nov 6, 2014)

Chris_H said:


> *Thank you*, jrm, for taking the time to share that with me!
> *Greatly* appreciated.
> 
> All the best.
> ...


Well. Sadly. The build and installation of lang/gcc48 did _not_ fix it. graphics/dri still FAILS in the same location, with the same error. 

Thanks for the tips, and pointers. Even if they didn't resolve the problem. They were greatly appreciated.

--Chris


----------

