Re: How to best check a configuration of another port/package?
On 2019-06-08 9:57, Adam Weinberger wrote: On Sat, Jun 8, 2019 at 10:02 AM Gerald Pfeifer wrote: In https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237688 we had a user report against lang/gcc* ports that could be traced back to a certain functionality (option) in another port (devel/binutils) missing. In pseudo-code this could be addressed as follows in lang/gcc* .if $(binutils built statically) IGNORE= GCC requires dynamically linked binutils .endif Now the question is: How to implement something like this practically? What you have there won't work, because `make index` won't work, plus Makefiles shouldn't be doing external calls if they don't have to. You'll also have a problem whereby LOCALBASE isn't defined yet, and I don't believe that IGNORE after bsd.port.pre.mk will work (I could be wrong about that). You have two options: 1) Turn it into a pre-configure, which is slightly ugly for the end-user but still gets the job done pre-configure: if some file in binutils is static; then echo "NOPE"; exit 1; fi 2) (The correct way to do it) Create a binutils-static slave port, remove the static option from binutils proper, and depend specifically on the non-static port. Why is a slave port the correct option here instead of flavouring binutils? ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Cleaning up pkg-message
On Sat, Jun 8, 2019 at 12:29 PM Bob Eager wrote: > > On Sat, 8 Jun 2019 12:16:05 -0600 > Adam Weinberger wrote: > > > I want to get some stakeholder input on our pkg-message files. I think > > we need to have a clear policy about what does and doesn't belong in > > them, and I'd like to get your input. > > I agree. > > I recently noticed that one of my ports had been modified by the > previous committer. I had a pkg-message which was short and contained > concise, minimal information. I also has a README file, installed > in /usr/local/share/doc/... if the DOCS option was selected. > > The committer folded the README file into pkg-message, and I disagree > with this: > > 1) It added far too much bulk to pkg-message. > > 2) It meant that an end user (without access to the ports tree) didn't > have an immediate way to see the README contents. > > 3) The committer tacked the README file onto pkg-message without > noticing that there was a %%DOCSDIR%% to be expanded, so that is how it > appears in pkg-message. Committers have the prerogative to alter pkg-message as required, but as the maintainer you have every right to object. Which port is it? I'd be happy to fix that for you. # Adam -- Adam Weinberger ad...@adamw.org https://www.adamw.org ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Cleaning up pkg-message
On Sat, Jun 08, 2019 at 12:11:57PM -0600, Adam Weinberger wrote: > Hello everyone, > > I want to get some stakeholder input on our pkg-message files. I think > we need to have a clear policy about what does and doesn't belong in > them, and I'd like to get your input. > > pkg-message is shown to every user on every install. UPDATING is only > shown when users run `pkg updating` *and* /usr/ports/UPDATING exists. > I suspect that only a small proportion of users do that. Well, for folks who install pre-built packages, probably. For those of us who -- for at least some systems -- build from ports locally, I'm less confident: I check it for relevant entries that have been added since last time I updated installed ports on my laptop or local build machine (which is daily) or my work desktop (which is weekly). Mind, its utility falls a bit short of the mark: ref. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227193 > pkg-message needs to contain only highly relevant information. Many, > many ports have messages with irrelevant information that users are > likely to get message fatigue and ignore them entirely. I don't want > to pick on Joe Barbish, because his work is absolutely fantastic, but > dns/dns2blackhole/pkg-message is an example of a giant message that > tells users to do the same thing they always do for any port: > > > dns2blackhole > >Malware Prevention through Domain Blocking (Black Hole) > >Issue "man dns2blackhole" For configuration and usage information > > > > We now have the ability to specify messages that appear on initial > install, or on upgrades from/to specific version. So here is what I > propose as policy: > > >>> > pkg-message must contain only information that is vital to setup and > operation, and that is unique to the port in question. Setup > information should only be shown on initial install, and upgrade > instructions should be shown only when upgrading to the relevant > version. All committers have blanket approval to constrain existing > messages to install/upgrade ranges using the UCL format > specifications. Message pruning falls under the blanket approval as > well, but committers are encouraged to get maintainer input > beforehand. > <<< > > What are your thoughts? > No objections, and de-cluttering seems like a pretty good idea. (At least you didn't insert a requirement that any such messages must "spark joy." :-) ) Peace, david -- David H. Wolfskill da...@catwhisker.org "...including Mars (of which the Moon is a part)" -- Donald J. Trump See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: Cleaning up pkg-message
On Sat, 8 Jun 2019 12:16:05 -0600 Adam Weinberger wrote: > I want to get some stakeholder input on our pkg-message files. I think > we need to have a clear policy about what does and doesn't belong in > them, and I'd like to get your input. I agree. I recently noticed that one of my ports had been modified by the previous committer. I had a pkg-message which was short and contained concise, minimal information. I also has a README file, installed in /usr/local/share/doc/... if the DOCS option was selected. The committer folded the README file into pkg-message, and I disagree with this: 1) It added far too much bulk to pkg-message. 2) It meant that an end user (without access to the ports tree) didn't have an immediate way to see the README contents. 3) The committer tacked the README file onto pkg-message without noticing that there was a %%DOCSDIR%% to be expanded, so that is how it appears in pkg-message. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Cleaning up pkg-message
Hello everyone, I want to get some stakeholder input on our pkg-message files. I think we need to have a clear policy about what does and doesn't belong in them, and I'd like to get your input. pkg-message is shown to every user on every install. UPDATING is only shown when users run `pkg updating` *and* /usr/ports/UPDATING exists. I suspect that only a small proportion of users do that. pkg-message needs to contain only highly relevant information. Many, many ports have messages with irrelevant information that users are likely to get message fatigue and ignore them entirely. I don't want to pick on Joe Barbish, because his work is absolutely fantastic, but dns/dns2blackhole/pkg-message is an example of a giant message that tells users to do the same thing they always do for any port: dns2blackhole Malware Prevention through Domain Blocking (Black Hole) Issue "man dns2blackhole" For configuration and usage information We now have the ability to specify messages that appear on initial install, or on upgrades from/to specific version. So here is what I propose as policy: >>> pkg-message must contain only information that is vital to setup and operation, and that is unique to the port in question. Setup information should only be shown on initial install, and upgrade instructions should be shown only when upgrading to the relevant version. All committers have blanket approval to constrain existing messages to install/upgrade ranges using the UCL format specifications. Message pruning falls under the blanket approval as well, but committers are encouraged to get maintainer input beforehand. <<< What are your thoughts? # Adam -- Adam Weinberger ad...@adamw.org // ad...@freebsd.org https://www.adamw.org ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Cleaning up pkg-message
Hello everyone, I want to get some stakeholder input on our pkg-message files. I think we need to have a clear policy about what does and doesn't belong in them, and I'd like to get your input. pkg-message is shown to every user on every install. UPDATING is only shown when users run `pkg updating` *and* /usr/ports/UPDATING exists. I suspect that only a small proportion of users do that. pkg-message needs to contain only highly relevant information. Many, many ports have messages with irrelevant information that users are likely to get message fatigue and ignore them entirely. I don't want to pick on Joe Barbish, because his work is absolutely fantastic, but dns/dns2blackhole/pkg-message is an example of a giant message that tells users to do the same thing they always do for any port: dns2blackhole Malware Prevention through Domain Blocking (Black Hole) Issue "man dns2blackhole" For configuration and usage information We now have the ability to specify messages that appear on initial install, or on upgrades from/to specific version. So here is what I propose as policy: >>> pkg-message must contain only information that is vital to setup and operation, and that is unique to the port in question. Setup information should only be shown on initial install, and upgrade instructions should be shown only when upgrading to the relevant version. All committers have blanket approval to constrain existing messages to install/upgrade ranges using the UCL format specifications. Message pruning falls under the blanket approval as well, but committers are encouraged to get maintainer input beforehand. <<< What are your thoughts? # Adam -- Adam Weinberger ad...@adamw.org // ad...@freebsd.org https://www.adamw.org ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: How to best check a configuration of another port/package?
On Sat, Jun 8, 2019 at 10:02 AM Gerald Pfeifer wrote: > > In https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237688 we had > a user report against lang/gcc* ports that could be traced back to > a certain functionality (option) in another port (devel/binutils) > missing. > > In pseudo-code this could be addressed as follows in lang/gcc* > >.if $(binutils built statically) >IGNORE= GCC requires dynamically linked binutils >.endif > > Now the question is: How to implement something like this practically? What you have there won't work, because `make index` won't work, plus Makefiles shouldn't be doing external calls if they don't have to. You'll also have a problem whereby LOCALBASE isn't defined yet, and I don't believe that IGNORE after bsd.port.pre.mk will work (I could be wrong about that). You have two options: 1) Turn it into a pre-configure, which is slightly ugly for the end-user but still gets the job done pre-configure: if some file in binutils is static; then echo "NOPE"; exit 1; fi 2) (The correct way to do it) Create a binutils-static slave port, remove the static option from binutils proper, and depend specifically on the non-static port. # Adam -- Adam Weinberger ad...@adamw.org https://www.adamw.org ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
How to best check a configuration of another port/package?
In https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237688 we had a user report against lang/gcc* ports that could be traced back to a certain functionality (option) in another port (devel/binutils) missing. In pseudo-code this could be addressed as follows in lang/gcc* .if $(binutils built statically) IGNORE= GCC requires dynamically linked binutils .endif Now the question is: How to implement something like this practically? Gerald @FreeBSD.org ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ net/mpich | 3.2.1 | 3.3.1 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Thanks. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
