mixed enviroment(for desktop)

[wolffnx]

is dangerous have a mixed enviroment(%50 compiled from ports and %50 installed from pkg)?

Recently regain confidence in FreeBSD, In something I could not debug:

https://forums.freebsd.org/threads/59458/

i follow my steps in every machine i have this problem and come up with a solution

install everything from pkg and when is needed compile from ports
today i'am using a FreeBSD desktop without fear for a firefox or thunar crash

What are your advice? is more easy to trace a problem when everything is installed from pkg?

 

[SirDice]

is dangerous have a mixer enviroment(%50 compiled from ports and %50 installed from pkg)?

I would advise against it as it is really easy to create conflicting situations with this (Package A depends on a certain option being enabled with package B).

If you only use the default options and never change anything, use packages. If you deviate from the defaults (different versions, different options) build from ports.

Or get the best of both worlds by building from ports using ports-mgmt/poudriere or ports-mgmt/synth and use the resulting packages in your own repository.

 

[wolffnx]

I would advise against it as it is really easy to create conflicting situations with this (Package A depends on a certain option being enabled with package B).

If you only use the default options and never change anything, use packages. If you deviate from the defaults (different versions, different options) build from ports.

Or get the best of both worlds by building from ports using ports-mgmt/poudriere or ports-mgmt/synth and use the resulting packages in your own repository.

exactly,It was my experience,and i't was sooo hard to detect the problem

 

[PacketMan]

is dangerous have a mixed enviroment(%50 compiled from ports and %50 installed from pkg)? ........ What are your advice? is more easy to trace a problem when everything is installed from pkg?

Very dangerous, although the problems it caused was one of my greatest sources of learning, which I guess is fine if its a home machine for recreational use/learning. If you're looking to get fired from your job, then yeah keep mixing.

Advice - do what SirDice said.

 

[Deleted member 48958]

When I read the titles, I thought it will be something about "how to launch gnome shell panel inside KDE 4"

Personally I'm using ports and pkg's mixed and don't have any problems at all, you just need to know what you are doing, when you installing something. I always create a package after building port as a backup with # make package and move it to /root/PKG directory, also it is possible to create a package, when port installation is already done before, with # pkg create.
For example

# cd /root/PKG
# pkg create vim
# mv vim-8.0.0325.txz vim-8.0.0325_GTK3.txz

Few times those backed up packages helped me a lot.
Also, when you use port and packages mixed, you'll encounter some issues with # pkg upgrade

Spoiler

But it is possible to upgrade, you just need to upgrade pkgs separately, for example # pkg upg gimp gnubc geany...


But if you do not want any problems, just use packages.
If you would like to use the newest versions, use the "latest" repository instead of default "quarterly" :
# mkdir -p /usr/local/etc/pkg/repos
# cp /etc/pkg/FreeBSD.conf /usr/local/etc/pkg/repos/FreeBSD.conf

Open /usr/local/etc/pkg/repos/FreeBSD.conf and edit the 11 line

FreeBSD: {
[b]  url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest",[/b]
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}

 

[wolffnx]

thanks for the comments

Very dangerous, although the problems it caused was one of my greatest sources of learning, which I guess is fine if its a home machine for recreational use/learning. If you're looking to get fired from your job, then yeah keep mixing.

Advice - do what SirDice said.

for now the "mix" is for home only
in my work i have a FreeBSD server with virtualbox headless running like hell only with packages

If you would like to use the newest versions, use the "latest" repository instead of default "quarterly" :

i'dont have the need for up to date packages,only for changes for example, gtk2 support for firefox and not gtk3

you just need to know what you are doing, when you installing something. I always create a package after building port as a backup with # make package and move it to /root/PKG directory, also it is possible to create a package, when port installation is already done before, with # pkg create.

its a very usefull info for my, but for basic packages without too many dependencies,like your example, "vi" or other like that
in X program like a file manager o web browser is a nightmare keep tracking the changes

 

[SirDice]

i'dont have the need for up to date packages,only for changes for example, gtk2 support for firefox and not gtk3

I highly recommend setting up your own repository. It may take a bit of fiddling to get it going but once it's there it's easy to update. This will also make sure you can actually build stuff using the options you selected without touching anything that's already running. Once everything is built it's just a matter of pkg upgrade to upgrade the packages with your settings. Build once, install many

 

[wolffnx]

I highly recommend setting up your own repository. It may take a bit of fiddling to get it going but once it's there it's easy to update. This will also make sure you can actually build stuff using the options you selected without touching anything that's already running. Once everything is built it's just a matter of pkg upgrade to upgrade the packages with your settings. Build once, install many

is a big..biggg step for my,i'l try it when i have more experience

 

[ASX]

is a big..biggg step for my

Not really, if you can read and understand this man page: synth(1) you are 99% ready to go, the remaining 1% being about configure ports options, but you can start with the defaults.

 

[wolffnx]

Not really, if you can read and understand this man page: synth(1) you are 99% ready to go, the remaining 1% being about configure ports options, but you can start with the defaults.

But if I build my own repository , would not interfere with the oficial repositories when i want to download something official?
i mean, Package A -> downloaded from official repositories
Package B -> my own package build with my own custom options

if Package A need certain option enabled in package B ?

 

[ASX]

But if I build my own repository , would not interfere with the oficial repositories when i want to download something official?

If you switch to build and use your own repository, when you will want a new software you will build it and use something like synth install <category/port>, that will assure always full compliance with your own settings.

 

[SirDice]

But if I build my own repository , would not interfere with the oficial repositories when i want to download something official?

The trick is to disable the official repository and only use your own. This is easily done by creating a few files in /usr/local/etc/pkg/repos/. That way you can be sure things are "matched" together. It does require a little more effort to build things but it pays off in the end because you don't have to struggle with competing or conflicting options.

 

[marino]

there is an option where officially-built packages can be downloaded and installed *if* the official build is compatible with your custom settings.
While conservatively it's recommended to build everything yourself, option '[N] Fetch prebuilt packages' set to true works pretty well, when the ports tree and last publish packages align (which isn't all the time).

In a rush, you can use prebuilt packages. If time is not an issue, best to build EVERYTHING yourself.

 

[ANOKNUSA]

you just need to know what you are doing

This is true of everything in life. I still think it's not good to advise newcomers to do something "if they know what they're doing." Most people don't know what they're doing, but in some circumstances will have convinced themselves that they do, simply because something hasn't gone horribly wrong yet. Terrible drivers will often say they're good drivers. How do they know they're good drivers? Because they haven't been in a fatal car wreck yet. Sure, they've been given some citations and been in some minor collisions, but those were totally someone else's fault, right?

 

[fscorrea]

Personally I'm using ports and pkg's mixed and don't have any problems at all

Me too, but I'm in the "home machine for recreational use/learning" case mentioned by PacketMan.

I use # make package as well and have the same issues regarding # pkg upgrade. At first I looked for something like Debian's apt-mark hold but couldn't find anything. I guess ports-mgmt/pkg purpose had no use for such a feature, and ease OS tweaking ("mixed-environment") probably wasn't considered a reason good enough.

Perhaps I should try a proper, "ports-built-only" clean install. But my spending over 2h building www/firefox once in the past makes me wonder if that's realistic an option.

Personally I'm using ports and pkg's mixed and don't have any problems at all

Me too, but I'm in the "home machine for recreational use/learning" case mentioned by PacketMan.

I use # make package as well and have the same issue regarding # pkg upgrade. At first I looked for something like Debian's apt-mark hold but couldn't find anything. I guess ports-mgmt/pkg purpose had no use for such a feature, and ease OS tweaking ("mixed-environment") probably wasn't considered good enough a reason.

Perhaps I should try a proper, "ports-built-only" clean install. But my spending over 2h building www/firefox once in the past makes me wonder if that's realistic an option.

 

[Deleted member 48958]

At first I looked for something like Debian's apt-mark hold but couldn't find anything

# pkg lock
I like ports-mgmt/pkg much, it's very intuitive. IMHO it is much better than apt-mark,
apt-cache, apt-get, apt-build, apt-go-to-sleep, etc or even pacman -Syisusu
It is even possible to create custom "alias" for pkg, just edit /usr/local/etc/pkg.conf:

. . .
# Sample alias settings
ALIAS              : {
  all-depends: query %dn-%dv,
  annotations: info -A,
  build-depends: info -qd,
  cinfo: info -Cx,
  comment: query -i "%c",
  csearch: search -Cx,
  desc: query -i "%e",
  download: fetch,
  iinfo: info -ix,
  isearch: search -ix,
  prime-list: "query -e '%a = 0' '%n'",
  leaf: "query -e '%#r == 0' '%n-%v'",
  list: info -ql,
  noauto = "query -e '%a == 0' '%n-%v'",
  options: query -i "%n - %Ok: %Ov",
  origin: info -qo,
  provided-depends: info -qb,
  raw: info -R,
  required-depends: info -qr,
  roptions: rquery -i "%n - %Ok: %Ov",
  shared-depends: info -qB,
  show: info -f -k,
  size: info -sq,
  }
. . .

But my spending over 2h building www/firefox once in the past makes me wonder if that's realistic an option.

I always build such ports when I go to sleep, and when I wake up — it's done

 

[mefizto]

Hi SirDice,

I would advise against it as it is really easy to create conflicting situations with this (Package A depends on a certain option being enabled with package B).

Can you please explain how does the ports-mgmt/synth prevent this situation?

If I understand the concepts, package is just an entity built from a port. So, if one enables certain options in port B and uses ports-mgmt/synth to build package B and then uses ports-mgmt/synth to build package A, it seems that the problem you described should arise, since port A has no way knowing about the option enabled in port B.

Or does ports-mgmt/synth keep track of the all the options thus enforcing compatibility?

Kindest regards,

M