How could I have the console font like DragonflyBSD?

It doesn't list which package first pulled python* in, it lists the packages requied by it. For multiple versions of python: pkg info -gr python\*
 
mjollnir said:
Maybe you're reading that from the Makefile of the port? I have only python27 & python37 pulled in. But I do not remember if I installed x11/xorg-minimal. How can I query pkg(8) which package pulled in python?
Click to expand...

I did a make run-depends-list

You can see similar results here though:
https://www.freebsd.org/cgi/ports.cgi?query=xorg-minimal&stype=all

I used to have a script which ran the above command recursively and made a tree diagram. I left it at work however and cannot get into the building for another few weeks haha.

For build dependencies, it is fairly easy to find. You just break the Python makefile and see where the main recursive xorg build fails and follow the "stack trace" XD
 
kpedersen said:
Similar to Xorg having dbus and nvidia driver having Linux compat options enabled by default.
Click to expand...

I've noticed those too. I don't think there have ever been two options i've spent less thought on while hitting deselect. Sadly something i installed later on still felt the need to pull in something related to dbus. Judging from the final result its seems this was luckily just dbus client libraries though. I avoid dbus (and all those poetterkits...) even on Linux so suddenly having it on FreeBSD would have been somewhat ironic.

kpedersen said:
That said, it does also drag in llvm80 (rather than link against the one in base) so I suppose C and C++ is only slightly better XD
Click to expand...

It's hard to miss this one when building the port. I think like 95% of the time spent getting X running was used building llvm80. If i remember correctly there also wasn't any obvious option to avoid it. On top of that it's pretty strange if you ask me. X being a really old codebase it's hard to think of reasons why there would be a need to use an overly recent compiler.
 
ekvz said:
X being a really old codebase it's hard to think of reasons why there would be a need to use an overly recent compiler.
Click to expand...

I *think* it is to do with LLVMpipe (the software rasteriser) or the AMD GPU related driver. Either they really do need the latest code generation technology, or it is because these are written by the FOSS kids who always want the latest stuff. In my experience, it is usually the latter. I also note that OpenBSD's Xenocara manages both of these just fine without it.

I am also fairly certain that once FreeBSD does end up with that version of LLVM in base (licensing concerns aside), those annoying things will be depending on an even newer version of LLVM (and almost certainly pull in another 4 versions of Python haha).

"Progress" is inelegant ;)
 
I'm using 11.4, it has LLVM 10 in base but I still need to have the llvm80 package installed. The reason I think is packages are still built for 11.3 and 11.3 has LLVM 8 in base. When 11.3 is EOL, I think my 11.4 will no longer need that llvm80 package.
 
kpedersen said:
Not to mention, the minimal X11 package dragging in 3 pythons kind of undoes the benefits of minimal anyway. Especially if you go and install a single Qt (or Gtk) application afterwards.
...
You know something is wrong with a language when a "minimal" meta-package drags in 3 versions of it.

Code:

python27
python35
python37
Click to expand...

I have x11/xorg-minimal installed, and only lang/pyton37 is on my system ( packages, no ports ). None of the other mentioned pythons is a required run dependency by any component or their dependecies of the meta package. lang/python27 appears in make all-depends-list, which I suspect is a build dependency of a dependency.
 
kpedersen said:
Similar to Xorg having dbus and nvidia driver having Linux compat options enabled by default. Annoying for package users.
Click to expand...

That is not the current ports ( automatically also the packages ) default configuration for the x11/nvidia-driver. The default is LINUX=off ( make -C /usr/ports/x11/nvidia-driver showconfig ) as of 2019-10-25:

/usr/ports/UPDATING
Code: 
2019-10-25

Affects: users of x11/nvidia-driver (and slave ports)

Author: danfe@FreeBSD.org

Reason:
  x11/nvidia-driver* ports no longer install Linux programs and libraries,
  which had been moved to their own ports (x11/linux-nvidia-libs*).  When
  updating the driver package next time, remember to install them manually
  if you need to run Linux OpenGL programs.

[EDIT] Sorry, I hadn't run make rmconfig. What kpedersen said about the linux compatibility is valid. I apologize.
 
T-Daemon said:
I have x11/xorg-minimal installed, and only lang/pyton37 is on my system ( packages, no ports ). None of the other mentioned pythons is a required run dependency by any component or their dependecies of the meta package. lang/python27 appears in make all-depends-list, which I suspect is a build dependency of a dependency.
Click to expand...

T-Daemon said:
That is not the current ports ( automatically also the packages ) default configuration for the x11/nvidia-driver. The default is LINUX=off ( make -C /usr/ports/x11/nvidia-driver showconfig ) as of 2019-10-25:
Click to expand...

Yes, it's quite possible this situation has been resolved by now. I am still running an older version of ports with the plan being to update them later all at once or simply reinstall the whole system when i have figured out how i want it to be set up.
 
T-Daemon said:
[EDIT] Sorry, I hadn't run make rmconfig. What kpedersen said about the linux compatibility is valid.
Click to expand...

I know there was some discussion about changing the default but I guess the maintainer decided against it. In all fairness I don't have a better solution, it would be annoying to recompile the port whether you do or don't want Linux support and yet providing two versions of the package (i.e as flavours) does increase the complexity of the ports collection.

T-Daemon said:
I have x11/xorg-minimal installed, and only lang/pyton37 is on my system ( packages, no ports ).
Click to expand...

Hmm, it seemed to drag in the extra pythons on mine. Perhaps it just considers me a user who needs more Python in their life? ;)
That said, I havne't updated packages in quite some time. I downloaded the entire pkg repo to my home network in Feb. It might be something that improved semi-recently.
 
kpedersen said:
I know there was some discussion about changing the default but I guess the maintainer decided against it. In all fairness I don't have a better solution, it would be annoying to recompile the port whether you do or don't want Linux support and yet providing two versions of the package (i.e as flavours) does increase the complexity of the ports collection.
Click to expand...

The problem of allowing full customization while not requiring the ports to be built locally is something i have been thinking about quite a bit lately but the only thing that came out of it yet is the realization that solving it in a fully flexible way is probably not easy and likely to involve some kind of remote build service (if that's practical is an entirely different topic of course).
 
pkg info -gr python\* | grep -Ev 'py[23]7-' | less does not list any native X11 ports require Python. Some Gtk and Plasma5 ports do, as well as applications, naturally. So pulling in Python via xorg or xorg-minimal seems to be a bug introduced in package management.
 
kpedersen said:
I know there was some discussion about changing the default but I guess the maintainer decided against it. In all fairness I don't have a better solution, it would be annoying to recompile the port whether you do or don't want Linux support and yet providing two versions of the package (i.e as flavours) does increase the complexity of the ports collection.
Click to expand...

SirDice, one more please, for completeness.

Despite the fact default is LINUX=on for the nvidia-driver, installing the port or package doesn't drag in the Linux compatibility layer as if was before 2019-10-25. That does now x11/linux-nvidia-libs, but that port is not a required dependency for the driver.

Seen that way it's an improvement. Before the separation of Linux programs and libraries from the driver I had to build from port with Linux disabled. I don't need the linux compatibility layer, and I hate to have unnecessary dependencies installed if I can opt them out.
 
You must log in or register to reply here.
Back
Top