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

Chris_H

Chris_H

...or, yet another reason to hate pkg(8). :P
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):
Code: 
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) :P
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
 
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.
 
SirDice said:
Keep in mind that 11-CURRENT is an unsupported version.

Topics about unsupported FreeBSD versions
Click to expand...
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
 
Juanitou said:
Sorry if I’m being obtuse, but how your problem is related to pkg(8)?
Click to expand...
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
 
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? :)
Click to expand...
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.
 
talsamon said:
xmmintrin.h is in "/usr/local/lib/compilername/..". What says echo $PATH ?
Click to expand...
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
 
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.
Click to expand...
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
 
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
Click to expand...
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…
 
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
 
% pkg which /usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd10.0/4.8.3/include/xmmintrin.h
Code: 
/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
 
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.
Click to expand...
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.
Click to expand...
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 inflexible, 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
 
jrm said:
% pkg which /usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd10.0/4.8.3/include/xmmintrin.h
Code: 
/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
Click to expand...
Thank you, jrm, for taking the time to share that with me!
Greatly appreciated.

All the best.

--Chris
 
Chris_H said:
Thank you, jrm, for taking the time to share that with me!
Greatly appreciated.

All the best.

--Chris
Click to expand...
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
 
You must log in or register to reply here.
Back
Top