Pkg tool needs some common sense?

Guest

@doktornotor:

@yon:

yes, me too, ipv6 all down in v2.4.1, i have to back to 2.4.0 ok.

This is NOT the thread for debugging your broken 12WAN setups. Kindly leave it alone.

Are there any rules to limit the number of use? Is this a child's toy? Not a professional tool？ ???
I would like any product to be tested in a complex and rigorous environment in order to find possible problems, rather than fear of problems and not dare to use.

Perhaps your requirements need professional support, here's the link to enable you to purchase it. https://www.pfsense.org/get-support/

perlenbacher

At least that support will come without all the snipey comments and abuse. Probably a good buy…

chrcoluk

@kpa:

You can put this into /usr/local/etc/pkg.conf to force the use of just IPv4:
IP_VERSION=4
You can also disable autofetching of the repo catalogs on every operation.
REPO_AUTOUPDATE=NO
That might mess with the GUI updater though, use with care.

excellent thank you.

I will see if I can get someone to add options for this in the GUI.

chrcoluk

@yon:

yes, me too, ipv6 all down in v2.4.1, i have to back to 2.4.0 ok.

I dont blame blame 2.4.1 for the ipv6 issue, it was down to an exotic config I had in place, and was just coincidence this is the first time I have ran a restore with that config which broke ipv6.

My ipv6 has been fine since I fixed the config issue. I waited to fix it as was advised in the pfsense UI to not make any config changes with a config restore in process.

Guest

@chrcoluk:

@kpa:
You can put this into /usr/local/etc/pkg.conf to force the use of just IPv4:
IP_VERSION=4
You can also disable autofetching of the repo catalogs on every operation.
REPO_AUTOUPDATE=NO
That might mess with the GUI updater though, use with care.
excellent thank you.

I will see if I can get someone to add options for this in the GUI.

OK Chris, I've added the two you mentioned in the email, threw me a bit as they are ENV vars now, no longer in a conf file!

Do you or anyone else want other vars added, the two that shout at me are these:

FETCH_RETRY: integer
Number of times to retry a failed fetch of a file. Default:
3.

FETCH_TIMEOUT: integer
Maximum number of seconds to wait for any one file to down-
load from the network, either by SSH or any of the protocols
supported by fetch(3) functions. Default: 30.

chrcoluk

thanks bud, I will give it a whirl later today :)

Guest

@chrcoluk:

thanks bud, I will give it a whirl later today :)

Forget the package timout & retry, they are already set to 5 & 2 respectively in the code anyway.

doktornotor

@marjohn56:

@chrcoluk:

thanks bud, I will give it a whirl later today :)

Forget the package timout & retry, they are already set to 5 & 2 respectively in the code anyway.

Yeah that has no effect at all on anything.

Guest

@doktornotor:

@marjohn56:

@chrcoluk:

thanks bud, I will give it a whirl later today :)

Forget the package timout & retry, they are already set to 5 & 2 respectively in the code anyway.

Yeah that has no effect at all on anything.

Perhaps the two I've added will have some effect, at least the use v4 one might.

FranciscoFranco

@doktornotor:

Otherwise, "intelligence" and pkg does not go together, and FreeBSD seems to be extremely unlucky when it comes to package managers. First the PBI junk, now this.

As a daily user of FreeBSD I can say wholeheartedly that pkg-ng is not broke and works quite well. Don't mix ports and packages.
I have see an freebsd-update that went awry and messed with a library needed for pkg, but pkg-static handled that.

After some recent run ins with Linux installers I think FreeBSD installer is on par with the others.

These timeouts have nothing to do with FreeBSD. This is a pfSense problem.

pkg-ng does work well offline. I am using it in my NanoBSD-build chroot making packages for cross-arch usage.

Plus you can use pkg add your.txz to feed FreeBSD packages files in an offline state.
You do have to provide all the dependencies too.

It works exactly as it should from my encounters. None of the installers are perfect from my usage.
Not keeping your packages up to date can be a problem. On any platform.

I can't speak for pbi's because they were before my time. I was still over here rubbing two sticks together.
There are probably some bugs in pkg-ng but standard use cases it works like a champ.

My defense of FreeBSD pkg rests. There are plenty of broken things in FreeBSD to complain about but pkg ain't one of them.

chrcoluk

pkg add for FreeBSD packages on pfsense used to work perfect offline, but now tries to contact the pfsense repos, so seems new behaviour in 2.4.1, I have not tested yet if this is fixed with the config option to disabled forced repo checks.

On FreeBSD I typically use ports not pkg, as I have always preferred compiling to pre compiled stuff, so cant really comment on the pkg ng implementation on FreeBSD.

kpa

Pkg is fine but pfSense could use more sensible defaults like not autoupdating the repo catalogs every time, it is not required for proper operation. Also none of the options can not be changed via the webgui and the update system is now a giant black box that doesn't reveal any of its inner workings which makes debugging problems very hard.

Guest

@kpa:

Pkg is fine but pfSense could use more sensible defaults like not autoupdating the repo catalogs every time, it is not required for proper operation. Also none of the options can not be changed via the webgui and the update system is now a giant black box that doesn't reveal any of its inner workings which makes debugging problems very hard.

I've added a couple of options which Chris is going to test later. I can add more if needed.