Re: ports/158179: some packages do not fully honor -P dir option in pkg_add(1)
1. Spell out very clearly its purpose - is it to populate a jail, for example? Populating a chroot/jail is one purpose. Another is to test a new version of a package without messing up the existing version. There are bound to be other reasons. Compiling the port rather than installing a package isn't always a solution. Many ports are incredibly difficult to get compiled. PREFIX needs to be an install time variable, not compile time. ___ 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 07/19/2011 01:41 PM, Dieter BSD wrote: 1. Spell out very clearly its purpose - is it to populate a jail, for example? Populating a chroot/jail is one purpose. Another is to test a new version of a package without messing up the existing version. I don't see how these two goals are compatible. Any programs installed for the purpose of a chroot/jail will have to point to $PREFIX, whereas any programs installed for the purpose of testing it elsewhere will either have to point to $PREFIX (if the stuff it is pointing to was not installed by the current package and the -p option was invoked), or to $PKG_PREFIX (if the stuff it is pointing to was installed by the current package or the -P option was invoked). ___ 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)
1. Spell out very clearly its purpose - is it to populate a jail, for example? Populating a chroot/jail is one purpose. Whoops, it occurs to me that using -P to populate a chroot/jail would only work for simple cases. There is the -C option, but it needs to be a fairly complete file system, including everything normally needed by pkg_add to run which could be problematic, as you may want the chroot/jail to have the absolute minimum possible. So to populate a chroot/jail we'd want to be able to specify two directories: one for the real path, and one for the after-chrooting path. The -c option is available. Say a package has the binary bin/foo and the config file etc/foo.conf. 1) Pkg_add would install /usr/local/bin/foo and /usr/local/etc/foo.conf. 2) Pkg_add -P /bar would install /bar/bin/foo and /bar/etc/foo.conf. 3) Pkg_add -c /chroot would install /chroot/bin/foo and /chroot/etc/foo.conf. 4) Pkg_add -c /chroot -P /bar would install /chroot/bar/bin/foo and /chroot/bar/etc/foo.conf. In cases 2 and 4, the foo binary would have to have some way to know to look for foo.conf in /bar/etc rather than /usr/local/etc. Perhaps CONFIG_PATH ? But in the general case, we'd need a lot of *PATHs. Or a way to set PREFIX at install time. (But how?) Or...? ___ 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 Tue, 19 Jul 2011 18:41:31 +, Dieter BSD wrote: 1. Spell out very clearly its purpose - is it to populate a jail, for example? Populating a chroot/jail is one purpose. Corrupting the pkgdb there is a chroot option for that Another is to test a new version of a package without messing up the existing version. it will mess up the database either There are bound to be other reasons. Compiling the port rather than installing a package isn't always a solution. Many ports are incredibly difficult to get compiled. PREFIX needs to be an install time variable, not compile time. PREFIX at install time is just broken and can't be anything else than broken, because lot's of path given a build time configuration path for example, etc. ___ 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 ___ 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)
Baptiste Daroussin b...@freebsd.org writes: On Tue, 19 Jul 2011 18:41:31 +, Dieter BSD wrote: 1. Spell out very clearly its purpose - is it to populate a jail, for example? Populating a chroot/jail is one purpose. Corrupting the pkgdb there is a chroot option for that You would need to set the DBDIR to manage the databases properly (which makes sense because there really is a separate set of ports living in the jail). I agree about the chroot option, though; I do not see any reason that one would ever use -P rather than -C for populating a jail from the outside. Another is to test a new version of a package without messing up the existing version. it will mess up the database either One would just use a different database. As I said, that makes sense. This thread has already heard from one person who successfully uses the -P option for this purpose, so it's definitely useful to someone. There are bound to be other reasons. Compiling the port rather than installing a package isn't always a solution. Many ports are incredibly difficult to get compiled. PREFIX needs to be an install time variable, not compile time. PREFIX at install time is just broken and can't be anything else than broken, because lot's of path given a build time configuration path for example, etc. Yes. In general, packages just can't be placed anywhere other than where they were built for, and we can't do anything about that in the ports infrastructure. ___ 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 Sat July 16 2011 18:21:12 Chris Rees wrote:
Bear in mind they should work fine if the port doesn't hardcode absolute
paths.
Yes, they actually do! Please do not remove them, because they are not as
buggy as it is claimed here. I often use the -p option for testing of my
tinderbox -exp packages and it works fine.
A package is basically the same as an installed port - just with some
additional pkg meta data files all packed into a compressed tarball. If a
package contains hardcoded paths then the port is buggy not the package or
pkg_add. It is a general rule that ports should respect ${PREFIX}. If they do
not those ports need to be fixed.
I find it weird to think the -p / -P options should be removed from pkg_add.
Do not castrate the tool if some ports are buggy!
Thanks!
--
Regards
signature.asc
Description: This is a digitally signed message part.
Re: ports/158179: some packages do not fully honor -P dir option in pkg_add(1)
current - ports On 07/16/2011 09:02 PM, Adrian Chadd wrote: Unless say, you're doing package installation outside of a chroot/jail, to populate something inside a chroot/jail before you start said chroot/jail. I can see -P and -p working for those many ports which just put programs in place. But there are some ports that include installation programs as part of the software. And some ports (like octave) which have a program which sometimes acts as an installation script, and sometimes acts as a user program. And sometimes those installation programs install for the port, and sometimes they install for a subport. If we are to continue using the -P and -p options, I suggest someone does the following: 1. Spell out very clearly its purpose - is it to populate a jail, for example? 2. Set up a computer that tests each package to see if it is -P compliant and -p compliant. By the way, each should be tested separately. For example, suppose latex-pgf is installed with the -p option. Then does it expect mktexlsr to be in the directory it is installing into, or the regular directory? mktexlsr is installed by a dependency, so the package needs to know where to find it. It would seem to me that you need a PKG_LOCALBASE variable as well as a PKG_PREFIX variable, so that the port knows where to find these installation programs. 3. Add a flag to ports that allow the port maintainer to mark the port -p non-compliant and -P non-compliant. The other possibility is to add to the man page of pkg_add saying that there is a good chance the -p and -P options don't work properly. Some people have clearly indicated that they like and use these options, so let's keep them happy too, and not delete it altogether. Stephen ___ 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 17 July 2011 11:55, Marco Bröder marco.broe...@gmx.eu wrote:
On Sat July 16 2011 18:21:12 Chris Rees wrote:
Bear in mind they should work fine if the port doesn't hardcode absolute
paths.
Yes, they actually do! Please do not remove them, because they are not as
buggy as it is claimed here. I often use the -p option for testing of my
tinderbox -exp packages and it works fine.
A package is basically the same as an installed port - just with some
additional pkg meta data files all packed into a compressed tarball. If a
package contains hardcoded paths then the port is buggy not the package or
pkg_add. It is a general rule that ports should respect ${PREFIX}. If they do
not those ports need to be fixed.
I find it weird to think the -p / -P options should be removed from pkg_add.
Do not castrate the tool if some ports are buggy!
By no means is it a bug if paths are hardcoded into compiled binaries
-- it's common practice and unfortunately this will not change.
Another consequence of this is that most programs can't be relocated
to a different part of the filesystem.
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/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
