Re: Using portmaster with different PYTHON_VERSION
On 9/30/2010 11:59 PM, Dominic Fandrey wrote: I've been thinking whether I could abandon the assumption that there is only one package per origin in pkg_upgrade. I decided against it, because the change would be too fundamental. If the assumption was scrapped, there would no longer be a unique identifier for packages across versions and this would introduce guesswork into every layer of code. FWIW, I agree with you that this is a fundamental assumption and that it cannot be challenged without great peril. :) As far as I am concerned the correct solution would be to create py- slave ports for every major branch, i.e. py2-* and py3-* ports. This way you could have one python version from every major branch, which I'd expect to suffice for most use cases. I agree with you that this is likely the best solution, and while I'm not a python person I would use this approach if a similar situation presented itself with my perl ports. hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!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"
Re: Using portmaster with different PYTHON_VERSION
On 01/10/2010 01:04, Doug Barton wrote: > On 9/29/2010 1:57 PM, Dmitry Pryanishnikov wrote: >> Hello! >> >> 2010/9/28 Doug Barton: >>> >>> I would also argue that there is a fundamental assumption in the ports >>> infrastructure that what you're doing here (installing both versions >>> on the >>> same system) is not supported. The ability to make the version of things >>> like python or perl variable is a great feature of the ports >>> infrastructure, >>> but my understanding has always been that this would be a system-wide >>> option, and that installing different versions of the same language >>> on the >>> same system is not supported. >> >>What problems (besides no support in portmaster) can arise due to >> parallel use of Python 2 and Python 3 in the same FreeBSD system? > > I'm not an expert on python so I'll let someone more knowledgeable > comment on that. There may not even be any problems. I'd assume this is a correct assumption. I wouldn't expect any problems. > My point was simply > that historically the assumption has been that there would only be one > version of a given interpreted language (like perl or python, and to > some extent php, and others) on a system at a time. Your post eloquently > stated the case for why that assumption might no longer be true. If > that's the case, then the way we do some things might have to change. I've been thinking whether I could abandon the assumption that there is only one package per origin in pkg_upgrade. I decided against it, because the change would be too fundamental. If the assumption was scrapped, there would no longer be a unique identifier for packages across versions and this would introduce guesswork into every layer of code. There is already tons of guesswork in reading the command line parameters, there are 13 different things that can go wrong with packages specified on the command line. Because they can go wrong in different situations (e.g. regular reinstall request or -o), the code currently produces 19 different kinds of error messages just for specified package names. There are another 38 error messages for redundant and conflicting options/flags. Imagine to introduce this degree of error handling into every layer of a package management tool. As far as I am concerned the correct solution would be to create py- slave ports for every major branch, i.e. py2-* and py3-* ports. This way you could have one python version from every major branch, which I'd expect to suffice for most use cases. An alternative would be to have the py-* packages depend on lang/python and make that depend on more than one version of python. I.e. it should allow to select all desired python versions through the OPTIONS framework. The py-* ports then would have to be changed to install themselves for all available python versions they support (this should be possible with a little Makefile magic and dynamic plists). I expect this approach would also work well with the build systems pointyhat and tinderbox. If the ports tree introduced a new unique identifier that crossed version boundaries, was present in INDEX files, +CONTENTS files and of course could be produced by the Makefile, it would be far less trouble to get rid of the origin 1-1 package relation assumption. It would be a lot of work, because the assumption is so heavily relied on, but it would not be very difficult. Regards, Dominic -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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: Using portmaster with different PYTHON_VERSION
On 9/29/2010 1:57 PM, Dmitry Pryanishnikov wrote: Hello! 2010/9/28 Doug Barton: I would also argue that there is a fundamental assumption in the ports infrastructure that what you're doing here (installing both versions on the same system) is not supported. The ability to make the version of things like python or perl variable is a great feature of the ports infrastructure, but my understanding has always been that this would be a system-wide option, and that installing different versions of the same language on the same system is not supported. What problems (besides no support in portmaster) can arise due to parallel use of Python 2 and Python 3 in the same FreeBSD system? I'm not an expert on python so I'll let someone more knowledgeable comment on that. There may not even be any problems. My point was simply that historically the assumption has been that there would only be one version of a given interpreted language (like perl or python, and to some extent php, and others) on a system at a time. Your post eloquently stated the case for why that assumption might no longer be true. If that's the case, then the way we do some things might have to change. hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!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"
Re: Using portmaster with different PYTHON_VERSION
> The reason is because PORTSDIR has not been defined at this point. > The PORTSDIR variable is defined in /usr/ports/Mk/bsd.port.mk. Also > bsd.port.mk doesn't get included until after the master port's > Makefile gets included. Oh yes, you're absolutely right. I completely forgot that bsd.port.mk ist not yet included at that point. Thank you very much for your explanation! Sorry again, for the annoying question and best regards, Klaus ___ 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: Using portmaster with different PYTHON_VERSION
On Wed, Sep 29, 2010 at 10:40 PM, Scot Hetzel wrote:
> On Wed, Sep 29, 2010 at 2:53 AM, Klaus T. Aehlig wrote:
>>
>> Hi everybody,
>>
>> sorry for the noise.
>>
>>> > MASTERDIR= ${.CURDIR}/../py-httplib2
>>>
>>> shouldn't that be
>>>
>>> MASTERDIR=${PORTSDIR}/www/py-httplib2
>>>
>>> Or have I misunderstood something here?
>>
>> I obviously did. At least the example in porters' handbook and
>> all slave ports use ${.CURDIR}/../ Could some help me improve
>> my understanding and explain why it is preferable to refer to the
>> location of the current port in the file system rathen than to a
>> particular port in the ports tree?
>>
> Using this Makefile:
>
> #
>
> .include "${PORTSDIR}/www/py-httplib2
>
> will cause make to try to access the www/py-httplib2 directory in the
> current directory.
>
small correction, it will try to access /www/py-httplib2 directory
Scot
___
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: Using portmaster with different PYTHON_VERSION
On Wed, Sep 29, 2010 at 2:53 AM, Klaus T. Aehlig wrote:
>
> Hi everybody,
>
> sorry for the noise.
>
>> > MASTERDIR= ${.CURDIR}/../py-httplib2
>>
>> shouldn't that be
>>
>> MASTERDIR=${PORTSDIR}/www/py-httplib2
>>
>> Or have I misunderstood something here?
>
> I obviously did. At least the example in porters' handbook and
> all slave ports use ${.CURDIR}/../ Could some help me improve
> my understanding and explain why it is preferable to refer to the
> location of the current port in the file system rathen than to a
> particular port in the ports tree?
>
Using this Makefile:
#
.include "${PORTSDIR}/www/py-httplib2
will cause make to try to access the www/py-httplib2 directory in the
current directory.
The reason is because PORTSDIR has not been defined at this point.
The PORTSDIR variable is defined in /usr/ports/Mk/bsd.port.mk. Also
bsd.port.mk doesn't get included until after the master port's
Makefile gets included.
This is the reason why slave ports use:
MASTERDIR= ${.CURDIR}/../
.include "${MASTERDIR}/Makefile"
Scot
___
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: Using portmaster with different PYTHON_VERSION
Hello!
2010/9/28 Doug Barton :
>> Those packages (py26-httplib2 vs py31-httplib2) do not
>> conflict (they may be used simultaneously, don't overwrite each
>> other's files etc.). But they have single origin, which seems to
>> confuse the portmaster:
>>
>> PYTHON_VERSION=python2.6 portmaster www/py-httplib2
>> ===>>> Installation of www/py-httplib2 (py26-httplib2-0.6.0) complete
>> PYTHON_VERSION=python3.1 portmaster www/py-httplib2
>> ===>>> Upgrade of py26-httplib2-0.6.0 to py31-httplib2-0.6.0 complete
>
> I would also argue that there is a fundamental assumption in the ports
> infrastructure that what you're doing here (installing both versions on the
> same system) is not supported. The ability to make the version of things
> like python or perl variable is a great feature of the ports infrastructure,
> but my understanding has always been that this would be a system-wide
> option, and that installing different versions of the same language on the
> same system is not supported.
What problems (besides no support in portmaster) can arise due to
parallel use of Python 2 and Python 3 in the same FreeBSD system? I
see none: the resulting packages (python{26,31}-* and py{26,31}-*)
install files in different locations (they use e.g.
/usr/local/lib/python2.6 vs /usr/local/lib/python3.1). Moreover;
during the current stage of the Python's development there are
legitimate reasons for using Python 2 for some projects and Python 3
for the rest ( http://wiki.python.org/moin/Python2orPython3 ). And I
don't
expect that this situation will change soon (changes in Python 3 are
rather essential, so many packages will stay Python2-only for some
time)...
Well, as for me - it's not difficult to manage python2/3 packages
using just plain ports infrastructure. Thanks for explanation!
--
Sincerely, Dmitry
nic-hdl: LYNX-RIPE
___
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: Using portmaster with different PYTHON_VERSION
> MASTERDIR= ${.CURDIR}/../py-httplib2
shouldn't that be
MASTERDIR=${PORTSDIR}/www/py-httplib2
Or have I misunderstood something here?
Best regards,
Klaus
___
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: Using portmaster with different PYTHON_VERSION
Hi everybody,
sorry for the noise.
> > MASTERDIR= ${.CURDIR}/../py-httplib2
>
> shouldn't that be
>
> MASTERDIR=${PORTSDIR}/www/py-httplib2
>
> Or have I misunderstood something here?
I obviously did. At least the example in porters' handbook and
all slave ports use ${.CURDIR}/../ Could some help me improve
my understanding and explain why it is preferable to refer to the
location of the current port in the file system rathen than to a
particular port in the ports tree?
Best reagrds and please excuse my last mail.
Klaus
___
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: Using portmaster with different PYTHON_VERSION
On Tue, Sep 28, 2010 at 1:30 PM, Dmitry Pryanishnikov
wrote:
> Hello!
>
> I'm trying to install Python additional ports (e.g. www/py-httplib2)
> for different Python versions (2.6 and 3.1) in the same system using
> the portmaster. Those packages (py26-httplib2 vs py31-httplib2) do not
> conflict (they may be used simultaneously, don't overwrite each
> other's files etc.). But they have single origin, which seems to
> confuse the portmaster:
>
> PYTHON_VERSION=python2.6 portmaster www/py-httplib2
> ...
> ===>>> Installation of www/py-httplib2 (py26-httplib2-0.6.0) complete
>
> Then
>
> PYTHON_VERSION=python3.1 portmaster www/py-httplib2
> ...
> ===>>> Upgrade of py26-httplib2-0.6.0 to py31-httplib2-0.6.0 complete
>
> So portmaster thinks that it's an upgrade, and removes py26-httplib2,
> which is not correct - I want to keep both packages:
>
> py26-httplib2-0.6.0 A comprehensive HTTP client library
> py31-httplib2-0.6.0 A comprehensive HTTP client library
>
> Am I missing some portmaster's tunable, or it just doesn't support
> such ports yet?
>
The simplest way to solve this problem is for you to create a
www/py26-httplib2 port:
md /usr/ports/www/py26-httplib2
then create /usr/ports/www/py26-httplib2/Makefile with these contents:
# Local Ports Makefile for: py26-httplib2
PYTHON_VERSION=python2.6
MASTERDIR= ${.CURDIR}/../py-httplib2
.include "${MASTERDIR}/Makefile"
Finally, deinstall your py26-httplib2 install, and re-install from
www/py26-httplib2.
Scot
___
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: Using portmaster with different PYTHON_VERSION
On 9/28/2010 11:30 AM, Dmitry Pryanishnikov wrote: Hello! I'm trying to install Python additional ports (e.g. www/py-httplib2) for different Python versions (2.6 and 3.1) in the same system using the portmaster. Those packages (py26-httplib2 vs py31-httplib2) do not conflict (they may be used simultaneously, don't overwrite each other's files etc.). But they have single origin, which seems to confuse the portmaster: PYTHON_VERSION=python2.6 portmaster www/py-httplib2 ... ===>>> Installation of www/py-httplib2 (py26-httplib2-0.6.0) complete Then PYTHON_VERSION=python3.1 portmaster www/py-httplib2 ... ===>>> Upgrade of py26-httplib2-0.6.0 to py31-httplib2-0.6.0 complete So portmaster thinks that it's an upgrade, and removes py26-httplib2, which is not correct - I want to keep both packages: py26-httplib2-0.6.0 A comprehensive HTTP client library py31-httplib2-0.6.0 A comprehensive HTTP client library Am I missing some portmaster's tunable, or it just doesn't support such ports yet? You're not missing anything. Portmaster's assumption is that $ORIGIN is always unique. I would also argue that there is a fundamental assumption in the ports infrastructure that what you're doing here (installing both versions on the same system) is not supported. The ability to make the version of things like python or perl variable is a great feature of the ports infrastructure, but my understanding has always been that this would be a system-wide option, and that installing different versions of the same language on the same system is not supported. That said, assuming that the 2 ports create different /var/db/pkg directories, and do not install files into the same location, you could use portmaster's -g option for the first install, then re-install the package after installing the second port. Or you could just not use portmaster for the second one. hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!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"
Using portmaster with different PYTHON_VERSION
Hello! I'm trying to install Python additional ports (e.g. www/py-httplib2) for different Python versions (2.6 and 3.1) in the same system using the portmaster. Those packages (py26-httplib2 vs py31-httplib2) do not conflict (they may be used simultaneously, don't overwrite each other's files etc.). But they have single origin, which seems to confuse the portmaster: PYTHON_VERSION=python2.6 portmaster www/py-httplib2 ... ===>>> Installation of www/py-httplib2 (py26-httplib2-0.6.0) complete Then PYTHON_VERSION=python3.1 portmaster www/py-httplib2 ... ===>>> Upgrade of py26-httplib2-0.6.0 to py31-httplib2-0.6.0 complete So portmaster thinks that it's an upgrade, and removes py26-httplib2, which is not correct - I want to keep both packages: py26-httplib2-0.6.0 A comprehensive HTTP client library py31-httplib2-0.6.0 A comprehensive HTTP client library Am I missing some portmaster's tunable, or it just doesn't support such ports yet? -- Sincerely, Dmitry nic-hdl: LYNX-RIPE ___ 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"
