I have an application looking for python3.. been a while since I've done this and have vague memories that you shouldn't just create a symlink? How should I solve this issue? On 15.

ibs: there's a python3 package that provides it

ibs: but if you're trying to create a port for it, you may want to massage it to not use the python3 link

kevans_: Ah, the python3 package is basically a symlink?

ibs: yes, it's a dependency on the underlying python3 version and a symlink to its python binaries & pkgconfig

Perfect. Thanks.

last i checked we try not to have *ports* depend on it, but it'll be maintained for *users* that want to depend on it

do you know what the freebsd equivalent of this would be? apt-file search bin/blah im trying to find what package a known binary would be in

pkg search/pkg info?

im still looking too thought id ask the pros

i think those are just if its in the package name?

elivoncoder, I don't know if there is a better way but there is a pkg-provides plugin for pkg. "pkg install pkg-provides" then follow the "pkg info -D pkg-provides" instructions to configure pkg to use it. Then "pkg provides -u" to update the database. Then it can be used. Whew! To use it "pkg provides /usr/local/bin/bash" for example.

ooh thx rwp ill try it now

right on man thats exactly what i was looking for, thanks agian!

Glad to have helped! I had the same question when I migrated from Debian to FreeBSD.

Fun thoughts: with the SFC v Vizio fight going on, I wonder how many new FreeBSD corporate adopters we'll have

so from what I can gather, there is no system equivalent to `update-alternatives' in freebsd; if you have (for example) five different versions of lua installed, none of them will actually be /usr/bin/lua, and it's up to you to create such symlinks yourself?

technomancy: It ends up being a safer mechanism as you'll never be surprised by what version you get.

you can just say the feature doesn't exist; you don't have to try to sell me on it =)

technomancy: Rather than creating symlinks, have your scripts or code that depends on such a tool reference the "fully qualified" path.

technomancy: I'm saying it's a misfeature.

I'm keenly aware of "we don't have that so no one needs it" and this is distinct.

hard-coding a link to a fully qualified path in this would cause a lot more portability problems than it solves

technomancy: It'd guarantee that you never have unexpected behaviour from a different version of your tool.

no, it would guarantee me that the build would fail on every other OS

Might of course depend on the tool and any relevant standards. Like, /bin/sh should always be POSIX-compliant, without diverging capabilities.

technomancy: Surely you understand my point, though.

I understand that you have a point which would apply in other circumstances that are different from this one, yes

technomancy: Taking an extreme example, /usr/bin/python would be a fun one.

this build deliberately works and is tested across all versions of lua, so locking it in to one specific version is a bad idea

Is it Python 2? 3? What version of 3? That landscape shifts so radically that minor versions are going to be the difference between breaking and working.

sure; I guess that would be a problem if I were a python user?

It would be. Be grateful you're not.

But yeah, I think you're on the right page. You'll want to create symlinks yourself if you want a single path to a lua interpreter. Maybe create it with some set-up tool that you ship with your code.

until I tried freebsd I thought it was a given that `/usr/bin/env lua' would just work everywhere.

learn something new every day I guess =\

Well. env will cover you if it's called "lua" and it exists in your path, but it won't cover different names, yeah.

I mean, I assumed every lua programmer would have "lua" of some kind on their $PATH

technomancy: Given that ports aren't generally per-release, they're shared across releases, you could always depend on a specific version and reference it. Maybe even have your set-up make a compatibility symlink based on the version you've selected. Since the systems will likely exist to run your service, this level of control seems reasonable.

Then you just shift when your selected version ages out of ports.

I've been on both sides of the "carry your environment around on your back" argument (vs "use the system-supplied tools") and the "carry it around on your back" side usually wins.

for context here, I'm an upstream maintainer of a project that uses lua (5.1, 5.2, 5.3, 5.4, 5.5, and luajit) who is using freebsd for the first time since 2003 but I'm not packaging anything for freebsd or using freebsd as a server. I'm just curious about the experience a freebsd user would have if they ran a git clone on my codebase and tried to use it.

technomancy: Might not be a terrible idea to submit your project as a port and make it a truly seamless experience for users on FreeBSD.

oh, it's already a port

Ah, cool.

I am thinking more if they want to contribute patches and stuff

I miss seeing all the current version info on the FreeBSD.org homepage. :(

technomancy: If they've got the chops to contribute code, I wouldn't worry about their being hit with a missing symlink. :)

spork_css: Me too, but I like the new look anyway.

yeah, but it's nice when everything just works with zero hiccups

Agreed.

All websites look the same now, it's all kind of boring, but then again I guess we should be happy some people browse outside the walled garden of social media and discord servers.

Every time I talk about computers these past few years I feel like I'm channeling Grandpa Simpson. Everyone's a whipper-snapper to me now.

I've heard that freebsd has a work-in-progress policy which will prevent LLM-generated content from being accepted; is this true?

technomancy: Nothing is resolved there yet. I hope that ends up being the case though.

I really hope so

yeah, this is one thing really appealing to me about freebsd over debian

debian seems committed to admitting defeat

"back in my day we had AltaVista AND Yahoo AND google AND Jeeves AND for some reason a search engine run by Wired magazine"

There are folks working on such a policy for Debian too, but that's even further off being resolved.

I'd say linux in general has surrendered to the AI mania

Don't forget raging.com, even if it was just a pointer to AltaVista.

technomancy, good news, IMHO. Then it can be delisted from <codeberg.org/small-hack/open-slopware#user-content-bsd-based> .

I tried netbsd because they actually do have a policy finalized and published but the installer failed hard =)

I get developer complaints about not being able to have multiple versions of things installed within pkgs/ports and then that whole weird thing of "well, we have php83, php84 and php85, but if you want php83 with X version of postgresql-pdo, we gotta roll it for you".

But I also don't use linux nearly enough to see how they deal with that stuff.

spork_css: Common is one symlink for a chosen version and the rest available as named versions, like what technomancy is describing.

Or sometimes a configurable version, although that's growing less common.

weirdly this slop DOS seems like a case where having an enormous breadth of programs packaged (re: debian) is more of a liability than a strength

slop DOS? -- FreeDOS?

haha, no. just this ongoing attack where programs are getting ruined by slop code, like rsync.

rsync is tained with LLM code, but is it really ruined?

I mean, the current version randomly corrupts files?

ant-x: Folks are reporting that it's no longer working.

and the maintainer is just getting started

Hello technomancy! Nice to see you here.

I don't know.

the test suite got replaced with a generated joke that asserts a bunch of tautologies

Such a basic tool ruined. Perhaps the Unison file sychroniser is still OK.

ant-x: there is also openrsync which seems ok. but coordinating replacements is going to be a ton of work and I don't think each individual OS/distro can do it on their own.

*replacements and rollbacks

spork_css: AskJeeves, da bomb

jrm: thanks for your packaging work! btw in cgit.freebsd.org/ports/tree/lang/fennel/Makefile the NATIVE_LUA_LIB and STATIC_LUA_LIB settings should not be needed as it looks like you're doing a script/shebang build instead of a binary build

technomancy: I can't remember why I added those to the make environment. I'm just calling the build target in your Makefile, which in turn calls the fennel and fennel.lua targets.

Do they cause any problems? If so, I'll make the fix now, otherwise I'll change it on the next update.

no problems; just unnecessary

out of curiosity, where does LUA_VER come from?

unrelated: I use gitlab.com/thomasross/mirage for resizing and cropping images, but it's not in freebsd. anyone got a recommended alternative?

also unrelated: why is pandoc not called "pandoc"?

technomancy: It comes from cgit.freebsd.org/ports/tree/Mk/Uses/lua.mk, which gets pulled in because of the USES=lua.

I can look at porting mirage.

ah I see; USES is like an include-type directive?

oh, I don't care that much about mirage specifically. I just figured ... bsd users certainly crop images, right? I can use whatever yall use. =)

You can see how the USES= works from cgit.freebsd.org/ports/tree/Mk/bsd.port.mk, which all ports pull in.

I tend to use gimp, but that's certainly overkill, so I'm also interested to hear of a simpler alternative.

ImageMagick is the swiss army knife for that kind of stuff

ok so I normally do not use the mouse for many things. but I make an exception for cropping images.

=)

What terminal emulator is cool these days

I switched to alacritty; I like how it has the ability to open URLs from the keyboard

heard wezterm is nice but it's not widely packaged yet

Thanks. Gonna try alacritty.

Ugh. I just looked at freebsd.org. I miss the old view. And TIL Apple replaced with OpenRsync in macos.

o0x1eef: You can try foot

sakura is winning atm

I'm trying to replace rsync with openrsync and cbsd is like "no, I must have it." :-/ Trying to find a way to lie to it