Re: Opinion on cross-port OPTIONS CONFLICTS
That's why you do slave port with an option toggled, when you need a package you can depend on. OPTIONS haven't changed this aspect. But you can't readily specify option X enabled, option Y disabled on that slave port. You can, that's the point. There may come a time when it's decided to either have vanilla plists and seperate one(s) with options or dont track plists for non default options at all. I bet most/many non-default ports don't get properly packaged anyway as it is. Port needs to package cleanly with any combination of OPTIONS specified. If it doesn't, it needs to be fixed. -- Pav Lucistnik [EMAIL PROTECTED] on the road via OpenWebMail ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Opinion on cross-port OPTIONS CONFLICTS
On Friday 21 December 2007 10:33:44 pm Edwin Groothuis wrote: On Fri, Dec 21, 2007 at 09:05:18PM -0600, Josh Paetzel wrote: It also doesn't work if someone runs make rmconfig, or make config again and changes things after the port is installed. It probably doesn't work if a package was used to install either. Create a slave port audio/arts-withoutnas and let it depends on that one. I don't think that's a scalable solution. It would create an explosion of ports in the already taxed tree, as well as confusion as to which port to install among the users. And what is your solution for this problem? Edwin My initial solution as I posted is to register the OPTIONs used to build a port in /var/db/pkg -- Thanks, Josh Paetzel PGP: 8A48 EF36 5E9F 4EDA 5A8C 11B4 26F9 01F1 27AF AECB signature.asc Description: This is a digitally signed message part.
Re: Opinion on cross-port OPTIONS CONFLICTS
On Sat, Dec 22, 2007 at 11:50:53AM -0600, Josh Paetzel wrote: On Friday 21 December 2007 10:33:44 pm Edwin Groothuis wrote: On Fri, Dec 21, 2007 at 09:05:18PM -0600, Josh Paetzel wrote: It also doesn't work if someone runs make rmconfig, or make config again and changes things after the port is installed. It probably doesn't work if a package was used to install either. Create a slave port audio/arts-withoutnas and let it depends on that one. I don't think that's a scalable solution. It would create an explosion of ports in the already taxed tree, as well as confusion as to which port to install among the users. And what is your solution for this problem? My initial solution as I posted is to register the OPTIONs used to build a port in /var/db/pkg And how is that going to resolve the issue earlier suggestions suffered from with regarding to ports which are not installed yet but which will be installed as a dependency of this port? Edwin -- Edwin Groothuis |Personal website: http://www.mavetju.org [EMAIL PROTECTED]| Weblog: http://www.mavetju.org/weblog/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Opinion on cross-port OPTIONS CONFLICTS
On Saturday 22 December 2007 03:32:56 pm Edwin Groothuis wrote: On Sat, Dec 22, 2007 at 11:50:53AM -0600, Josh Paetzel wrote: On Friday 21 December 2007 10:33:44 pm Edwin Groothuis wrote: On Fri, Dec 21, 2007 at 09:05:18PM -0600, Josh Paetzel wrote: It also doesn't work if someone runs make rmconfig, or make config again and changes things after the port is installed. It probably doesn't work if a package was used to install either. Create a slave port audio/arts-withoutnas and let it depends on that one. I don't think that's a scalable solution. It would create an explosion of ports in the already taxed tree, as well as confusion as to which port to install among the users. And what is your solution for this problem? My initial solution as I posted is to register the OPTIONs used to build a port in /var/db/pkg And how is that going to resolve the issue earlier suggestions suffered from with regarding to ports which are not installed yet but which will be installed as a dependency of this port? Edwin Well, my idea was you'd be able to CONFLICT based on OPTIONs set in another port, so at least you could die with a helpful error message if they weren't set properly. -- Thanks, Josh Paetzel PGP: 8A48 EF36 5E9F 4EDA 5A8C 11B4 26F9 01F1 27AF AECB signature.asc Description: This is a digitally signed message part.
Opinion on cross-port OPTIONS CONFLICTS
I've recently run across some brokeness in ports that would be relatively trivial to deal with if one port had a way to know about the OPTIONS another port was compiled with. My initial thought was to register the state of OPTIONS in to /var/db/pkg. This solves all of the problems that I know of (not that I know all of them, but it fixes what I've found that's broken) but also involves quite a bit of work to the pkg_* tools. It was suggested to me that one could set up something such that CONFLICT_FILE=blah which would cover the case of an OPTION in another port causing it to install files that it wouldn't otherwise. This is far far easier to impliment, but does not solve all of the problems I've found. Another suggestion was to list the state of OPTIONS in the package name. I haven't really chewed on this one much. Here are two examples of situations where things are broken and it's tough to fix under the existing infrastructure: 1) random-example-app has ruby support but breaks with a threaded ruby installation. (CONFLICT_FILE wouldn't help here) 2) subversion and apache22 can overwrite each other's apr if you don't tell them about each other. Here's an example of how to duplicate this: install subversion without -DWITH_APACHE2_APR so it installs it's own apr. install apache22 and don't select use apr from ports from the menu. deinstall subversion. It will complain that md5s are wrong on apr because apache installed it's own there. Obviously this is doing it wrong, but in my opinion ports shouldn't be able to overwrite each other. Anyways, suggestions/feedback welcome. -- Thanks, Josh Paetzel PGP: 8A48 EF36 5E9F 4EDA 5A8C 11B4 26F9 01F1 27AF AECB signature.asc Description: This is a digitally signed message part.
Re: Opinion on cross-port OPTIONS CONFLICTS
On Fri, Dec 21, 2007 at 03:24:20PM -0600, Josh Paetzel wrote:
I've recently run across some brokeness in ports that would be relatively
trivial to deal with if one port had a way to know about the OPTIONS another
port was compiled with.
I have been working on it a not-so-long-time-ago and found that
this could be the best way:
[/var/db/ports/arts] [EMAIL PROTECTED]cat options
# This file is auto-generated by 'make config'.
# No user-servicable parts inside!
# Options for arts-1.5.1_1,1
_OPTIONS_READ=arts-1.5.1_1,1
WITHOUT_ESD=true
WITHOUT_NAS=true
[/var/db/ports/arts] [EMAIL PROTECTED]eval `cat options | grep -v ^\# | sed
-e 's/^/arts_/'`
[/var/db/ports/arts] [EMAIL PROTECTED]echo $arts_WITHOUT_NAS
true
I hadn't put it in a PR yet because it has some synchronity issues:
- It only works for ports already installed.
- It doesn't work for ports which are being installed by this port.
- No idea how to do this for packages build on ye olde cluster.
But the idea is there:
OPTIONS_DEPENDS=arts
.include bsd.port.pre.mk
.if !defined arts_WITH_NAS
BROKEN= Please build audio/arts first before building this port.
.fi
.if ${arts_WITH_NAS} = true
BROKEN= This port can't work with audio/arts enabled with NAS
support
.fi
Edwin
--
Edwin Groothuis |Personal website: http://www.mavetju.org
[EMAIL PROTECTED]| Weblog: http://www.mavetju.org/weblog/
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Opinion on cross-port OPTIONS CONFLICTS
On Friday 21 December 2007 03:43:19 pm Edwin Groothuis wrote:
On Fri, Dec 21, 2007 at 03:24:20PM -0600, Josh Paetzel wrote:
I've recently run across some brokeness in ports that would be relatively
trivial to deal with if one port had a way to know about the OPTIONS
another port was compiled with.
I have been working on it a not-so-long-time-ago and found that
this could be the best way:
[/var/db/ports/arts] [EMAIL PROTECTED]cat options
# This file is auto-generated by 'make config'.
# No user-servicable parts inside!
# Options for arts-1.5.1_1,1
_OPTIONS_READ=arts-1.5.1_1,1
WITHOUT_ESD=true
WITHOUT_NAS=true
[/var/db/ports/arts] [EMAIL PROTECTED]eval `cat options | grep -v ^\# |
sed -e
's/^/arts_/'`
[/var/db/ports/arts] [EMAIL PROTECTED]echo $arts_WITHOUT_NAS
true
I hadn't put it in a PR yet because it has some synchronity issues:
- It only works for ports already installed.
- It doesn't work for ports which are being installed by this port.
- No idea how to do this for packages build on ye olde cluster.
But the idea is there:
OPTIONS_DEPENDS= arts
.include bsd.port.pre.mk
.if !defined arts_WITH_NAS
BROKEN= Please build audio/arts first before building this port.
.fi
.if ${arts_WITH_NAS} = true
BROKEN= This port can't work with audio/arts enabled with NAS
support
.fi
Edwin
It also doesn't work if someone runs make rmconfig, or make config again and
changes things after the port is installed.
It probably doesn't work if a package was used to install either.
--
Thanks,
Josh Paetzel
PGP: 8A48 EF36 5E9F 4EDA 5A8C 11B4 26F9 01F1 27AF AECB
signature.asc
Description: This is a digitally signed message part.
Re: Opinion on cross-port OPTIONS CONFLICTS
On Friday 21 December 2007 22:43:19 Edwin Groothuis wrote:
On Fri, Dec 21, 2007 at 03:24:20PM -0600, Josh Paetzel wrote:
I've recently run across some brokeness in ports that would be relatively
trivial to deal with if one port had a way to know about the OPTIONS
another port was compiled with.
I have been working on it a not-so-long-time-ago and found that
this could be the best way:
[/var/db/ports/arts] [EMAIL PROTECTED]cat options
# This file is auto-generated by 'make config'.
# No user-servicable parts inside!
# Options for arts-1.5.1_1,1
_OPTIONS_READ=arts-1.5.1_1,1
WITHOUT_ESD=true
WITHOUT_NAS=true
[/var/db/ports/arts] [EMAIL PROTECTED]eval `cat options | grep -v ^\# |
sed -e
's/^/arts_/'`
[/var/db/ports/arts] [EMAIL PROTECTED]echo $arts_WITHOUT_NAS
true
I hadn't put it in a PR yet because it has some synchronity issues:
- It only works for ports already installed.
- It doesn't work for ports which are being installed by this port.
- No idea how to do this for packages build on ye olde cluster.
But the idea is there:
OPTIONS_DEPENDS= arts
.include bsd.port.pre.mk
.if !defined arts_WITH_NAS
BROKEN= Please build audio/arts first before building this port.
.fi
.if ${arts_WITH_NAS} = true
BROKEN= This port can't work with audio/arts enabled with NAS
support
.fi
Edwin
I like the idea to do something with options. Optionifying ports is all nice
and well, but to make it meaningful, ports should be able to know about each
other's options. I actually have been working a bit on a proposal that was
similar (it remained in brainstorm phase though ;-).
How about e.g. LIB_DEPENDS=artsdsp:/usr/portss/[EMAIL PROTECTED] to squash two
flies at once.
The idea being that if the port is not installed it yet, it could be built
with make WITHOUT_NAS=1 automagically. Something like this is more pressing
when you need to have a non-default option set in a port you depend on.
However, you should be very careful to not decide things on the users behalf
in a port. Consistancy, pola, all that...
Cheers,
Dan
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Opinion on cross-port OPTIONS CONFLICTS
Danny Pansters píše v so 22. 12. 2007 v 00:07 +0100: How about e.g. LIB_DEPENDS=artsdsp:/usr/portss/[EMAIL PROTECTED] to squash two flies at once. The idea being that if the port is not installed it yet, it could be built with make WITHOUT_NAS=1 automagically. Something like this is more pressing when you need to have a non-default option set in a port you depend on. However, you should be very careful to not decide things on the users behalf in a port. Consistancy, pola, all that... This would not work for the packages. How would you represent such a dependency line in a package? That's why you do slave port with an option toggled, when you need a package you can depend on. OPTIONS haven't changed this aspect. -- Pav Lucistnik [EMAIL PROTECTED] [EMAIL PROTECTED] Orfax's hip flask contained Old Janx Spirit, a mixture of potions of stupidity, paralysis, naivery, ruination, lose memories, confusion, and slime mold juice, with a twist of lemon. - from a post on Angband Community Forum signature.asc Description: Toto je digitálně podepsaná část zprávy
Re: Opinion on cross-port OPTIONS CONFLICTS
--On December 22, 2007 12:07:45 AM +0100 Danny Pansters [EMAIL PROTECTED] wrote: I like the idea to do something with options. Optionifying ports is all nice and well, but to make it meaningful, ports should be able to know about each other's options. I actually have been working a bit on a proposal that was similar (it remained in brainstorm phase though ;-). How about e.g. LIB_DEPENDS=artsdsp:/usr/portss/[EMAIL PROTECTED] to squash two flies at once. Another way to address this would be to create a fourth tuple. Right now the convention is file:portdir:target. Why not have file:portdir:target:option. The problem with this whole subject is, what do you do if a port depends on another port *and* requires that _more_than_one_option be true? My idea doesn't solve that *unless* you allow a comma separated list or something similar. I think, if you're going to make ports OPTIONS aware, you *must* be able to both determine if a port is already installed with or without the option *and* install it with the necessary options if it's not already installed. The idea being that if the port is not installed it yet, it could be built with make WITHOUT_NAS=1 automagically. Something like this is more pressing when you need to have a non-default option set in a port you depend on. However, you should be very careful to not decide things on the users behalf in a port. Consistancy, pola, all that... OTOH, if you can't build your port without a dependency including an option, why not mark the port as BROKEN unless the correct file is in place? The first tuple already checks for that, right? So, instead of checking for the default file, check for something the OPTION would install. So: LIB_DEPENDS=ldap.so:net/openldap for without the OPTION or LIB_DEPENDS=ldapfoo.so:net/openldap for with the OPTION That doesn't solve *installing* the dependency correctly without some other construct such as the fourth tuple though. Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Opinion on cross-port OPTIONS CONFLICTS
I bet most/many non-default ports don't get properly packaged anyway as it is. I meant: ports with non-default OPTIONS. Sorry. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Opinion on cross-port OPTIONS CONFLICTS
On Saturday 22 December 2007 01:29:23 Pav Lucistnik wrote: Danny Pansters píše v so 22. 12. 2007 v 00:07 +0100: How about e.g. LIB_DEPENDS=artsdsp:/usr/portss/[EMAIL PROTECTED] to squash two flies at once. The idea being that if the port is not installed it yet, it could be built with make WITHOUT_NAS=1 automagically. Something like this is more pressing when you need to have a non-default option set in a port you depend on. However, you should be very careful to not decide things on the users behalf in a port. Consistancy, pola, all that... This would not work for the packages. How would you represent such a dependency line in a package? Hmm, yes, I think I know what you mean. OPTION_DEPENDS has similar problem unless specifically listed in plist + some magic. Bummer. That's why you do slave port with an option toggled, when you need a package you can depend on. OPTIONS haven't changed this aspect. But you can't readily specify option X enabled, option Y disabled on that slave port. I'm not sure if we'd actually want this now, considering the baggage (esp with pkgs, I barely considered them). You can always do local discovery inside a particular port by looking at installed files, or grepping ldd, or other specific hackery -- including grepping on /var/db/ports/foo/options -- and you will be able to cater to that port's needs that way and guide (not force) the user. Even this is hard, if not impossible to put into packages/plist. There may come a time when it's decided to either have vanilla plists and seperate one(s) with options or dont track plists for non default options at all. I bet most/many non-default ports don't get properly packaged anyway as it is. What I mean is, that maybe we shouldn't even try to support packaging non-default builds, and leave it to the person behind the keyboard instead. Not because I like this option so much, but because I fear something like that is going to be inevitable in the near future. Are you, or any other folks, aware of any projects (not ones that were recently on this ML!! :) that are working on a radical modernization of ports? Not that I feel we necessary need one here and now, but I'm interested in any (serious, as in code) ports-v2 efforts. cmake has many useful ports-like features. Cheers, Dan ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Opinion on cross-port OPTIONS CONFLICTS
On Fri, Dec 21, 2007 at 04:13:46PM -0600, Josh Paetzel wrote:
On Friday 21 December 2007 03:43:19 pm Edwin Groothuis wrote:
On Fri, Dec 21, 2007 at 03:24:20PM -0600, Josh Paetzel wrote:
I've recently run across some brokeness in ports that would be relatively
trivial to deal with if one port had a way to know about the OPTIONS
another port was compiled with.
I have been working on it a not-so-long-time-ago and found that
this could be the best way:
[/var/db/ports/arts] [EMAIL PROTECTED]cat options
# This file is auto-generated by 'make config'.
# No user-servicable parts inside!
# Options for arts-1.5.1_1,1
_OPTIONS_READ=arts-1.5.1_1,1
WITHOUT_ESD=true
WITHOUT_NAS=true
[/var/db/ports/arts] [EMAIL PROTECTED]eval `cat options | grep -v ^\# |
sed -e
's/^/arts_/'`
[/var/db/ports/arts] [EMAIL PROTECTED]echo $arts_WITHOUT_NAS
true
I hadn't put it in a PR yet because it has some synchronity issues:
- It only works for ports already installed.
- It doesn't work for ports which are being installed by this port.
- No idea how to do this for packages build on ye olde cluster.
But the idea is there:
OPTIONS_DEPENDS=arts
.include bsd.port.pre.mk
.if !defined arts_WITH_NAS
BROKEN= Please build audio/arts first before building this port.
.fi
.if ${arts_WITH_NAS} = true
BROKEN= This port can't work with audio/arts enabled with NAS
support
.fi
Edwin
It also doesn't work if someone runs make rmconfig, or make config again and
changes things after the port is installed.
It probably doesn't work if a package was used to install either.
Create a slave port audio/arts-withoutnas and let it depends on
that one.
Edwin
--
Edwin Groothuis |Personal website: http://www.mavetju.org
[EMAIL PROTECTED]| Weblog: http://www.mavetju.org/weblog/
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Opinion on cross-port OPTIONS CONFLICTS
On Friday 21 December 2007 07:50:59 pm Edwin Groothuis wrote:
On Fri, Dec 21, 2007 at 04:13:46PM -0600, Josh Paetzel wrote:
On Friday 21 December 2007 03:43:19 pm Edwin Groothuis wrote:
On Fri, Dec 21, 2007 at 03:24:20PM -0600, Josh Paetzel wrote:
I've recently run across some brokeness in ports that would be
relatively trivial to deal with if one port had a way to know about
the OPTIONS another port was compiled with.
I have been working on it a not-so-long-time-ago and found that
this could be the best way:
[/var/db/ports/arts] [EMAIL PROTECTED]cat options
# This file is auto-generated by 'make config'.
# No user-servicable parts inside!
# Options for arts-1.5.1_1,1
_OPTIONS_READ=arts-1.5.1_1,1
WITHOUT_ESD=true
WITHOUT_NAS=true
[/var/db/ports/arts] [EMAIL PROTECTED]eval `cat options | grep -v ^\#
| sed
-e 's/^/arts_/'`
[/var/db/ports/arts] [EMAIL PROTECTED]echo $arts_WITHOUT_NAS
true
I hadn't put it in a PR yet because it has some synchronity issues:
- It only works for ports already installed.
- It doesn't work for ports which are being installed by this port.
- No idea how to do this for packages build on ye olde cluster.
But the idea is there:
OPTIONS_DEPENDS= arts
.include bsd.port.pre.mk
.if !defined arts_WITH_NAS
BROKEN= Please build audio/arts first before building
this port.
.fi
.if ${arts_WITH_NAS} = true
BROKEN= This port can't work with audio/arts enabled
with NAS
support .fi
Edwin
It also doesn't work if someone runs make rmconfig, or make config again
and changes things after the port is installed.
It probably doesn't work if a package was used to install either.
Create a slave port audio/arts-withoutnas and let it depends on
that one.
Edwin
I don't think that's a scalable solution. It would create an explosion of
ports in the already taxed tree, as well as confusion as to which port to
install among the users.
--
Thanks,
Josh Paetzel
PGP: 8A48 EF36 5E9F 4EDA 5A8C 11B4 26F9 01F1 27AF AECB
signature.asc
Description: This is a digitally signed message part.
Re: Opinion on cross-port OPTIONS CONFLICTS
On Fri, Dec 21, 2007 at 09:05:18PM -0600, Josh Paetzel wrote: It also doesn't work if someone runs make rmconfig, or make config again and changes things after the port is installed. It probably doesn't work if a package was used to install either. Create a slave port audio/arts-withoutnas and let it depends on that one. I don't think that's a scalable solution. It would create an explosion of ports in the already taxed tree, as well as confusion as to which port to install among the users. And what is your solution for this problem? Edwin -- Edwin Groothuis |Personal website: http://www.mavetju.org [EMAIL PROTECTED]| Weblog: http://www.mavetju.org/weblog/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
