Re: RFC: change to bsd.perl.mk
On 07/15/2011 22:07, Mark Linimon wrote: Per Doug Barton's suggestion, I have reworked the long-standing patch to bsd.perl.mk to be an exact copy of the logic in bsd.port.mk, and done an -exp run. Does anyone have any objection if I commit this patch? This is actually the exact opposite of what I suggested. My suggestion is that we put all of the necessary perl stuff in bsd.perl.mk, and in bpm we make inclusion of bsd.perl.mk conditional on USE_PERL5. Following that change do an -exp run and ask for help fixing any ports that don't properly define USE_PERL5. If bsd.perl.mk is going to be included unconditionally, what's the point of having it in a separate file? Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
audio/musicpd and libsndfile dependency
Hello, I've just realized that libsndfile is required for musicpd. see : $ ldd /usr/local/bin/musicpd ... libFLAC.so.10 = /usr/local/lib/libFLAC.so.10 (0x802331000) libsndfile.so.1 = /usr/local/lib/libsndfile.so.1 (0x802468000) libaudiofile.so.0 = /usr/local/lib/libaudiofile.so.0 (0x8025d1000) ... And : $ pkg_info -R libsndfile-1.0.24 Information for libsndfile-1.0.24: Required by: sfml-1.6 It seems that musicpd implicitly link to libsndfile if it is installed on the system. May I propose a PR with a new option to disable/enable this linkage using an OPTION? Cheers, -- David Demelier ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: audio/musicpd and libsndfile dependency
On 16 Jul 2011 13:03, David Demelier demelier.da...@gmail.com wrote: Hello, I've just realized that libsndfile is required for musicpd. see : $ ldd /usr/local/bin/musicpd ... libFLAC.so.10 = /usr/local/lib/libFLAC.so.10 (0x802331000) libsndfile.so.1 = /usr/local/lib/libsndfile.so.1 (0x802468000) libaudiofile.so.0 = /usr/local/lib/libaudiofile.so.0 (0x8025d1000) ... And : $ pkg_info -R libsndfile-1.0.24 Information for libsndfile-1.0.24: Required by: sfml-1.6 It seems that musicpd implicitly link to libsndfile if it is installed on the system. May I propose a PR with a new option to disable/enable this linkage using an OPTION? Thank you, that would be most welcome. I would do it myself, but I think you'll be quicker at the moment... Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Fwd: Re: ports/158179: some packages do not fully honor -P dir option in pkg_add(1)
Taking out current@ and replacing with ports@
On 16 Jul 2011 16:38, Stephen Montgomery-Smith step...@missouri.edu
wrote:
On 07/16/2011 04:26 AM, Stefan Bethke wrote:
Am 16.07.2011 um 04:43 schrieb Stephen Montgomery-Smith:
I was looking through the source code of pkg_add. Personally I don't
see how the -P or -p option could be made to work with pkg_add. Many of
the installation commands involve scripts which have ${PREFIX} hard coded
into them. ${PREFIX} is often hard coded when trhe package is created by
the port. In my opinion, the options -p and -P should be removed from
pkg_add.
Either that, or provide the port a way to access @cwd in any scripts
it installs. But this would require a major overhaul of the whole ports
system, and probably much of the software it installs as well.
Am I missing something?
Yes. Not honoring the prefix is a bug in the port. If you do need to do
prefix-specific things during install, use pkg-install, see
http://www.freebsd.org/doc/en/books/porters-handbook/pkg-install.html
I suspect that many ports are not well tested outside of /usr/local,
but the infrastructure is there and available.
You are correct, this needs to be done on a port by port basis. In some
ports this is going to be a big job, because in some cases the /usr/local
is hard coded into certain binaries.
For example, suppose the C source code contains something like:
char applications_dir = /usr/local/share/applications;
and this is filled in by the ./configure script.
How is that handled?
It's not.
Remember what a package is, literally the files from the plist tarred with
some magic +FILEs and the pkg-*install files- if paths are hardcoded in
objects that's how it'll be installed.
Don't touch the -p option! It's only useful for um someone help
here?
Chris
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports/158179: some packages do not fully honor -P dir option in pkg_add(1)
Replacing current@ with ports@, just like Chris did.
On 07/16/2011 10:53 AM, Chris Rees wrote:
On 16 Jul 2011 16:38, Stephen Montgomery-Smith step...@missouri.edu
mailto:step...@missouri.edu wrote:
On 07/16/2011 04:26 AM, Stefan Bethke wrote:
Am 16.07.2011 um 04:43 schrieb Stephen Montgomery-Smith:
I was looking through the source code of pkg_add. Personally I
don't see how the -P or -p option could be made to work with
pkg_add. Many of the installation commands involve scripts which have
${PREFIX} hard coded into them. ${PREFIX} is often hard coded when trhe
package is created by the port. In my opinion, the options -p and
-P should be removed from pkg_add.
Either that, or provide the port a way to access @cwd in any
scripts it installs. But this would require a major overhaul of the
whole ports system, and probably much of the software it installs as well.
Am I missing something?
Yes. Not honoring the prefix is a bug in the port. If you do need
to do prefix-specific things during install, use pkg-install, see
http://www.freebsd.org/doc/en/books/porters-handbook/pkg-install.html
I suspect that many ports are not well tested outside of
/usr/local, but the infrastructure is there and available.
You are correct, this needs to be done on a port by port basis. In
some ports this is going to be a big job, because in some cases the
/usr/local is hard coded into certain binaries.
For example, suppose the C source code contains something like:
char applications_dir = /usr/local/share/applications;
and this is filled in by the ./configure script.
How is that handled?
It's not.
Remember what a package is, literally the files from the plist tarred
with some magic +FILEs and the pkg-*install files- if paths are
hardcoded in objects that's how it'll be installed.
What if some of the installation programs are binaries, and /usr/local
is hard coded into installation binaries or scripts provided by the
software itself.
Don't touch the -p option! It's only useful for um someone help
here?
I am thinking the same thing!
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports/158179: some packages do not fully honor -P dir option in pkg_add(1)
current@ to ports@ again. (Sorry, my mistake.) On 07/16/2011 11:10 AM, Chris Rees wrote: On 16 Jul 2011 17:04, Stephen Montgomery-Smith step...@missouri.edu mailto:step...@missouri.edu wrote: On 07/16/2011 10:53 AM, Chris Rees wrote: On 16 Jul 2011 16:38, Stephen Montgomery-Smith step...@missouri.edu mailto:step...@missouri.edu mailto:step...@missouri.edu mailto:step...@missouri.edu wrote: For example, suppose the C source code contains something like: char applications_dir = /usr/local/share/applications; and this is filled in by the ./configure script. How is that handled? It's not. Remember what a package is, literally the files from the plist tarred with some magic +FILEs and the pkg-*install files- if paths are hardcoded in objects that's how it'll be installed. What if some of the installation programs are binaries, and /usr/local is hard coded into installation binaries or scripts provided by the software itself. Sorry, poor wording on my part. No, I didn't read what you said properly. If it was compiled as prefix=/usr/local, that's how it'll be installed, regardless of your -p argument. So -p and -P are inherently buggy, and should be removed from pkg_add? (Or every port which uses prefix=/usr/local needs major revision and patching, which I think is an intolerable workload.) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports/144597: security/openssh-portable fails to compile with KERBEROS enabled
On 16 Jul 2011 00:23, Jason Hellenthal jh...@dataix.net wrote: On Wed, Jul 13, 2011 at 11:39:01PM -0500, Stephen Montgomery-Smith wrote: Hey people, I was looking over old unresolved PR's. I came across this one: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/144597 When I sent a message to the submitter of the PR, the email bounced back suggesting that the submitter no longer uses that email address. I don't think it would be too hard to make the port build under the circumstances he describes. But is ANYONE interested? Would it be worth investing effort to make this work? Note that the port has ports@ as its maintainer, so it doesn't look like there is a lot of interest. Thanks, Stephen P.S. This one is related: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/57498 Is this a big bag of worms? I can see that seems to be fixed, for example, in mail/fetchmail. Considering that the port version is 5.2p1 and the current version in stable/8 is 5.4p1 and greater than that for HEAD I would say it would be much more of a benefit to get the port updated to the latest version and then work on it from there, otherwise its a loss of time for an outdated version. Last time I looked at this port it was a mess with a collection of third party patches from all over the place which I think lead to a discrepancy in the update of the port but that's just my opinion. It would be nice to see a simplified version of this port so it isn't such a monster to update and have an option for a user supplied patches directory that stands outside of the tree (user configured path) and it just blindly attempts to apply what is in that directory. I think this would help slim it down a little so it can consistently be bumped to a new revision without hassle. Something like: # Defaults to /usr/ports/patches unless path is user specified. WITH_PATCH_TREE?=/usr/ports/patches /usr/ports/patches/ # Distributed empty. everything else user created. |-- net | `-- wireshark `-- security |-- gnupg `-- openssh-portable Things like this would certainly make it easier for a consistent user supplied patch to be kept local for build machines. I can't count the times on 2 hands and 2 feet that I wanted to patch a port with a local patch and had to continuously cp(1) a patch back to a ports tree using rsync(1) Not really, because that would encourage people to have local patches that quickly go stale. You should have to manually record the patches, because you should be checking they're still current each time. Otherwise we could end up with numerous bug reports because of this. Or do everyone a favour and link them to an OPTION with extra patches! Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports/158179: some packages do not fully honor -P dir option in pkg_add(1)
On 16 Jul 2011 17:18, Stephen Montgomery-Smith step...@missouri.edu wrote: current@ to ports@ again. (Sorry, my mistake.) On 07/16/2011 11:10 AM, Chris Rees wrote: On 16 Jul 2011 17:04, Stephen Montgomery-Smith step...@missouri.edu mailto:step...@missouri.edu wrote: On 07/16/2011 10:53 AM, Chris Rees wrote: On 16 Jul 2011 16:38, Stephen Montgomery-Smith step...@missouri.edu mailto:step...@missouri.edu mailto:step...@missouri.edu mailto:step...@missouri.edu wrote: For example, suppose the C source code contains something like: char applications_dir = /usr/local/share/applications; and this is filled in by the ./configure script. How is that handled? It's not. Remember what a package is, literally the files from the plist tarred with some magic +FILEs and the pkg-*install files- if paths are hardcoded in objects that's how it'll be installed. What if some of the installation programs are binaries, and /usr/local is hard coded into installation binaries or scripts provided by the software itself. Sorry, poor wording on my part. No, I didn't read what you said properly. If it was compiled as prefix=/usr/local, that's how it'll be installed, regardless of your -p argument. So -p and -P are inherently buggy, and should be removed from pkg_add? (Or every port which uses prefix=/usr/local needs major revision and patching, which I think is an intolerable workload.) They are only for internal and experimental use really anyway. Perhaps the manpage should mention that. Bear in mind they should work fine if the port doesn't hardcode absolute paths. Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: RFC: change to bsd.perl.mk
If bsd.perl.mk is going to be included unconditionally, what's the point of having it in a separate file? - perl team can make changes (e.g. minor version update of perl) without -exp run and portmgr approval. (I would still prefer to do -exp runs for major version updates, of course). - easier to read the code. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: RFC: change to bsd.perl.mk
On 16 Jul 2011 22:26, Mark Linimon lini...@lonesome.com wrote: If bsd.perl.mk is going to be included unconditionally, what's the point of having it in a separate file? - perl team can make changes (e.g. minor version update of perl) without -exp run and portmgr approval. (I would still prefer to do -exp runs for major version updates, of course). - easier to read the code. If it's unconditionally included, how does that exempt it from exp-runs? Surely it's equally risky to commit to it as bsd.port.mk, or have I missed something? Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
math/bamg
Does anyone want to take the math/bamg port? Or at least tell me that they use it? It is now at version 1.0.0, and the current version's master site has disappeared. Also, it seems to be part of freefem++, and that port has disappeared from the FreeBSD ports. If no-one responds I will set it to broken, deprecate it, and give it to po...@freebsd.org. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: RFC: change to bsd.perl.mk
On Sat, Jul 16, 2011 at 10:51:04PM +0100, Chris Rees wrote: If it's unconditionally included, how does that exempt it from exp-runs? Surely it's equally risky to commit to it as bsd.port.mk, or have I missed something? In a perfect world we'd have -exp runs for everything, I suppose. OTOH here in the real world there's plenty of lower-risk changes that can be done without. If in doubt, we can always do one. Take a look a the various commits in ports/Mk for examples of what's been done in the past. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: RFC: change to bsd.perl.mk
On 07/16/2011 17:35, Mark Linimon wrote: On Sat, Jul 16, 2011 at 10:51:04PM +0100, Chris Rees wrote: If it's unconditionally included, how does that exempt it from exp-runs? Surely it's equally risky to commit to it as bsd.port.mk, or have I missed something? In a perfect world we'd have -exp runs for everything, I suppose. OTOH here in the real world there's plenty of lower-risk changes that can be done without. If in doubt, we can always do one. Take a look a the various commits in ports/Mk for examples of what's been done in the past. A) If the file is unconditionally included the idea of administrative separation is false security. There is no reason that the appropriate perl folks can't have permission to twiddle that stuff in bpm. B) Focusing on this part of the problem detracts from the more important point that the thing should be conditionally included, and that whatever needs to be fixed to make that happen should be fixed. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
