alright...soliciting advice...I was going to write the port for gitstatus.

They have a custom build script which works on FreeBSD. I'm wondering...should I preserve it or try to write a Makefile?

The problem is...damn, this is confusing. Between missing headers and custom dependencies, writing a Makefile might become a serious ordeal

Is it normal to run custom build scripts rather than having a simple, clean Makefile?

i wouldn't say it's "normal" but if the package doesn't provide a makefile and expects you to use their build script, and the script works on freebsd, i would just keep using it

Are there other exmaples of that?

there's not benefit from writing a new build system unless you're going to submit it upstream, and iirc you said this project is defunct upstream

devel/boost-jam

thank you!

btw...seems kinda insecure to have thousands of people running a custom build script on their machines.

no more insecure than using a makefile, which also contains arbitrary shell commands

True, but in theory those shell commands are visible within FreeBSD

whereas a build script can change arbitrarily.

you mean because make prints the commands it runs while building? but you can just prefix the command with '@' to make it not do that

I don't follow you?

lets say I have a package called 'farhan' and it has a custom build script 'buildme.sh'. You can look at MAKE_CMD=buildme.sh and know that buildme.sh is running.

But I can arbitrarily change buildme.sh's contents.

yes, but if your package ships a Makefile, you could arbitrary change the Makefile's contents?

this is why distinfo includes the hash of the dist file, to know it's unchanged from when the maintainer submitted the port

you're right about boost-jam, I might use that as a template.

And...I am not familiar with distinfo, will research.

distinfo is one of the files you submit with your port along with Makefile, pkg-descr, etc., it's described in the porter's handbook

it isn't present with boost-jam

oh yes! I did read about that! Sorry, so many terms/concepts at once and its hard to remember just yet.

no, that's quite odd and i'm not sure why boost-jam doesn't have a distinfo, but almost all other ports do

ah, it's because boost-jam uses the distinfo from boost-all

and you're familiar with gitstatus?

(because it's a part of boost, not a standalone package)

i have never heard of gitstatus before, no

Hi. I just installed dma (DragonFly Mail Agent) on a Debian machine, since I'm already using happily under FreeBSD. I notice that under Debian there's no need to have the configuration files world readable: they are readable by the "mail" group, and /usr/sbin/dma is a setgid executable, having group mail of course

I think it is a good idea. If it actually is so, would it make sense to have the same setup under FreeBSD? Perhaps a default even

farhan: for the ports framework there is just some command(s) you run to build the project, the default is using make and some other build systems have support via USES, but you can write the do-build target in the port yourself, same with do-install and do-fetch (but you should override that last one only in really rare cases)

dacav: i would be mildly opposed to think, i think setuid executables are bad and if you want something unusual you're better off installing a proper MTA

s/to think/so this

ivy: it is setgid to a 'mail' group

dacav: yes

setuid executables introduce potential security issues to all systems that executable is installed on, but this functionality would only be used by a small subset of systems

why do you think it is bad?

OK, I understand the idea: if an exploit exists on that binary, you get to run arbitrary code with those permission granted

do you know if it's installed this way on DFBSD?

But in this specific case the permissions would be those accorded to the `mail` group, which would be reading of /etc/dma/*

...which is already the case for any user

so my argument is that there's no big risk

I don't know if it is installed this way on DFBSD

dacav: i don't think that is correct, e.g. /var/mail is by default 0775 root:mail, so anyone with gid mail can write arbitrary files there

I don't own a DFBSD system :)

gid mail might also be used for other things i can't think of off hand

I see. Would it make sense to have a different group perhaps? Or would it be too bloaty?

perhaps if we added a new 'dma' group and made dma setgid dma, that would be more reasonable

:)

dacav: you can find a PR and cc ivy@, i think this is not an unreasonable idea

find a PR?

dacav: however we need to check with DF to make sure the code has been audited for setgid installation

s/find a PR/file a PR

do you mean file a pull request?

ok

I will do that later :)

I never did it

as in file a problem report at bugs.freebsd.org

Sure enough! I'll be back in the evening! Thanks for your time

when you do that, put ivy⊙fo in the Cc: field

all this MTA talk reminds me I need to patch my qmail-remote executable (-:

FAQ. «are you a time traveller» no.