Skip Menu |
 
rt.cpan.org will be shut down on March 1st, 2021.

This queue is for tickets about the Math-BigInt CPAN distribution.

Report information
The Basics
Id: 25299
Status: resolved
Worked: 10 min
Priority: 0/
Queue: Math-BigInt

People
Owner: TELS [...] cpan.org
Requestors: ANDK [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 1.80
Fixed in: (no value)



Subject: Recursive dependencies
Download (untitled) / with headers
text/plain 150b
Math-BigInt-1.80 declares that it depends on bignum 0.19. bignum 0.19 declares that it depends on Math-BigInt 1.79. Intention or oversight? Thanks,
Intention. Well, half. If you install Math::BigInt into an empty system, then all is well, you will install updated versions of Math::BigRat, BigInt::FastCalc and bignum afterwards and their newest versions cope with BigInt. However, if you install first an older version of Math::BigInt and all the other modules, and *then* upgrade Math::BigInt to 1.80, things might break because the other modules do not get updated. The dependencies are set so that if you install Math::BigInt 1.80 and it detects an outdated bignum et. al. if "forces" you to upgrade these first. A side-effect of this is if you have Math::BigInt 1.78 or older, you might need to first install 1.79, then bignum 0.19, then Math::Bigint 1.80. I don't think this can be avoided though. The only other option (when we detect that the other modules are outdated upon Math::BigInt upgrade) would be to abord the Makefile.pl, but as you are well aware, there is a certain toolchain which can't cope with that :-) so I came up with this clever scheme as a workaround. Please tell me if this can be improved or simplified. all the bets, tels
CC: ANDK [...] cpan.org
Subject: Re: [rt.cpan.org #25299] Recursive dependencies
Date: Wed, 14 Mar 2007 06:05:35 +0100
To: bug-Math-BigInt [...] rt.cpan.org
From: andreas.koenig.7os6VVqR [...] franz.ak.mind.de (Andreas J. Koenig)
Show quoted text
>>>>> On Tue, 13 Mar 2007 13:45:53 -0400, " via RT" <bug-Math-BigInt@rt.cpan.org> said:
Show quoted text
Show quoted text
> Intention. Well, half.
Show quoted text
> If you install Math::BigInt into an empty system, then all is well, you > will install updated versions of Math::BigRat, BigInt::FastCalc and > bignum afterwards and their newest versions cope with BigInt.
Math-BigInt-1.80 declares that it depends on bignum 0.19. So "empty" system (whatever this means) or not, apparently you cannot install Math::BigInt 1.80 without installing bignum 0.19 and thus Math::BigInt 1.79 first. This looks like a case without precedent in the history of CPAN and as such should probably be explained a bit more as to why this could not be avoided with defensive programming. Show quoted text
> However, if you install first an older version of Math::BigInt and all > the other modules, and *then* upgrade Math::BigInt to 1.80, things might > break because the other modules do not get updated.
You seem to indicate that 1.79 or 1.80 broke some API? Show quoted text
> The dependencies are set so that if you install Math::BigInt 1.80 and it > detects an outdated bignum et. al. if "forces" you to upgrade these first.
Show quoted text
> A side-effect of this is if you have Math::BigInt 1.78 or older, you > might need to first install 1.79, then bignum 0.19, then Math::Bigint 1.80.
Show quoted text
> I don't think this can be avoided though.
If it cannot be avoided, please explain why. The CHANGES file says about 1.79 "Fix typos". So how is it unavoidable that bignum requires Math::BigInt 1.79 and cannot run with, say 1.78? Show quoted text
> The only other option (when we detect that the other modules are > outdated upon Math::BigInt upgrade) would be to abord the Makefile.pl, > but as you are well aware, there is a certain toolchain which can't cope > with that :-) so I came up with this clever scheme as a workaround.
Show quoted text
> Please tell me if this can be improved or simplified.
If the "modules" are so tightly coupled that they all have to be upgraded at once, I think they should be distributed in a single distribution file that upgrades them all at once. -- andreas
Subject: Re: [rt.cpan.org #25299] Recursive dependencies
Date: Wed, 14 Mar 2007 18:56:23 +0000
To: bug-Math-BigInt [...] rt.cpan.org
From: Tels <nospam-abuse [...] bloodgate.com>
Download (untitled) / with headers
text/plain 6.4k
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Moin, On Wednesday 14 March 2007 05:06:59 (Andreas J. Koenig) via RT wrote: Show quoted text
> Queue: Math-BigInt > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=25299 > >
> >>>>> On Tue, 13 Mar 2007 13:45:53 -0400, " via RT" > >>>>> <bug-Math-BigInt@rt.cpan.org> said:
> > > > <URL: http://rt.cpan.org/Ticket/Display.html?id=25299 > > > > > Intention. Well, half. > > > > If you install Math::BigInt into an empty system, then all is well, > > you will install updated versions of Math::BigRat, BigInt::FastCalc > > and bignum afterwards and their newest versions cope with BigInt.
> > Math-BigInt-1.80 declares that it depends on bignum 0.19. So "empty" > system (whatever this means) or not, apparently you cannot install > Math::BigInt 1.80 without installing bignum 0.19 and thus Math::BigInt > 1.79 first.
- - From my Makefile.PL: check_minimum_version ('Math::BigInt::FastCalc' => 0.12); check_minimum_version ('Math::BigInt::GMP' => 1.19); check_minimum_version ('Math::BigRat' => 0.17); check_minimum_version ('bignum' => 0.19); recommends 'Math::BigRat' => 0.17; recommends 'Math::BigInt::GMP' => 1.19; recommends 'bignum' => 0.19; sub check_minimum_version { my ($module, $version) = @_; my $v; eval " require $module; \$v = \$${module}::VERSION;"; # if the module is installed, but outdated, add it to the requirements if (defined $v && $v < $version) { requires $module => $version; } } The intention is to NOT require bignum unless it is already installed. If my code is broken in this regard, please tell me, because as far as I can see a non-installed bignum should generate no dependecy on bignum 0.19. On an empty system, bignum should not be required. [snip] Show quoted text
> > However, if you install first an older version of Math::BigInt and > > all the other modules, and *then* upgrade Math::BigInt to 1.80, > > things might break because the other modules do not get updated.
> > You seem to indicate that 1.79 or 1.80 broke some API?
There have been a few additions of new methods, and older math-libraries without these methods are not loaded. Plus there were some critical bugfixes in the other libraries. If you install just Math::BigInt, the other libraries are still borked. Hence the try to get FastCalc upgraded. bignum and BigRat are not that critical in this regard, but if there are old versions on the system detected, I just threw bignum and BigRat in for good measure. Show quoted text
> > The dependencies are set so that if you install Math::BigInt 1.80 and > > it detects an outdated bignum et. al. if "forces" you to upgrade > > these first. > > > > A side-effect of this is if you have Math::BigInt 1.78 or older, you > > might need to first install 1.79, then bignum 0.19, then Math::Bigint > > 1.80. > > > > I don't think this can be avoided though.
> > If it cannot be avoided, please explain why. The CHANGES file says > about 1.79 "Fix typos".
The change occured in 1.78, but I had to release 1.79 because I forgot to include the typo-fixes from bleadperl in 1.78. Show quoted text
> So how is it unavoidable that bignum requires > Math::BigInt 1.79 and cannot run with, say 1.78?
bignum can run with 1.77 etc. But if you install 1.80, the already installed bignum libraries SHOULD (not "must", just "should") be updated, too. FastCalc can run with 1.77. But if you install 1.78, 1.79 or 1.80, the already installed FastCalc library MUST be updated, too. (However, I forgot about this fact and this lead to a few problems). Show quoted text
> > The only other option (when we detect that the other modules are > > outdated upon Math::BigInt upgrade) would be to abord the > > Makefile.pl, but as you are well aware, there is a certain toolchain > > which can't cope with that :-) so I came up with this clever scheme > > as a workaround. > > > > Please tell me if this can be improved or simplified.
> > If the "modules" are so tightly coupled that they all have to be > upgraded at once, I think they should be distributed in a single > distribution file that upgrades them all at once.
That would be the other option, but it also means that you couldn't f.i. install Math::BigInt without a C-compiler. Which was the reason why the libraries were seperated in the first place. Actually, the libraries aren't that closely coupled, I just made a few mistakes when releasing packages and wanted to avoid that people get stuck with old versions on their system. I have said it many times in private emails and I say it again here: The system to declare dependencies is seriously lacking a few things that authors need to express. Just being able to declare "I need foo minimum version 1.00" isn't enough for all the practical situatins that arise, like that Foo 1.00 and 1.01 work, 1.02 is borked and 1.03 not yet released. Likewise, it is impossible to say "if you update this package, also update these packages". And that is what my "hack" in Makefile.PL tries to acomplish. Please note that this dependency can't even expressed in META.yml, so all I can do is check it at run time in Makefile.PL and act according if the situation arises. In "real" packaging systems, you just specify the requirements and dependencies (needs package X, Y but conflicts with Z, U and W) and the system does the rest. Unfortunately, for CPAN the dependencies can only be described in a very simple matter, which leads to needless code duplication inside Makefile.PL to craft this stuff on. And sometimes that extra code is even buggy :) If my way of handling this situation is not doing what I outlined above, please tell me so I can fix it. All the best, Tels - -- Signed on Wed Mar 14 18:56:13 2007 with key 0x93B84C15. View my photo gallery: http://bloodgate.com/photos PGP key on http://bloodgate.com/tels.asc or per email. "Memory is like an orgasm. It's a lot better if you don't have to fake it." -- Seymore Cray, on virtual memory -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iQEVAwUBRfhFV3cLPEOTuEwVAQLI8Qf7Br41s5A1MyI0qJaGZQGP9wywCNkAWY1v 0Pwb8QDoRjPG2f71YtXDn/zIpOfWuUziwMsgtVgg6lxmnVVjFxSMK3UuGU/95EyO ahnDS6b8czUIdNew0fqVjWHd/ifgl4WiMFbLztrgqcSaywgInv/th9jFdvz8/86B LNjNJ8TuR3mOKjoEQOJknPpKZEtWKNnO+BL/1bGvj8QeUagBQnq+r3+hCy0AyBMk vjv9Uxr1+KjCZYrLNwQ3Nb5jrPO0f9/Tm/8EBS+MjXdIP2vM7xI0pd4mK1oeFpaS IGDGIjI5lU6i7Zim9I037DrBdAAGovZvJnWRYh88L0a7iQ3WrxoXbA== =sh9v -----END PGP SIGNATURE-----
Subject: Re: [rt.cpan.org #25299] Recursive dependencies
Date: Thu, 15 Mar 2007 17:51:35 +0000
To: bug-Math-BigInt [...] rt.cpan.org
From: Tels <nospam-abuse [...] bloodgate.com>
Download (untitled) / with headers
text/plain 1.5k
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Moin, On Wednesday 14 March 2007 17:56:34 nospam-abuse@bloodgate.com via RT wrote: Show quoted text
> Queue: Math-BigInt > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=25299 > > > Moin,
[snip] I think what the problem is: user requests install Math::BigInt CPAN tries to install Math::BigInt 1.80 Math::BigInt 1.80 is found Math::BigInt 1.80 find bignum (old version) Math::BigInt sets requirement of 0.19 of bignum CPAN tries to install 0.19 of bignum bignum requires Math::BigInt 1.79 CPAN hunts down Math::BigInt and ses 1.80 (newest) CPAN tries to install Math::BigInt 1.80 [enter endless loop] Aww crap. Queue v1.81 of BigInt in 10... 9... 8... 7... All the best, tels - -- Signed on Thu Mar 15 17:48:57 2007 with key 0x93B84C15. Get one of my photo posters: http://bloodgate.com/posters PGP key on http://bloodgate.com/tels.asc or per email. "Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life." -- Terry Pratchett -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iQEVAwUBRfmHqHcLPEOTuEwVAQKdTgf/SpU/suc3lxAbpjU/u3pXugGXcopGJ/7q lg4Skk3J5b3oJLCI5h++76GadUJBkOFQTuoVHxJfCMyB0hjGAwbvKy4MMybbxJG/ B/m2RZY6u79qR+BNItljt54otifZL/B5gnRq/RRyR2YHiG8yYoDg6f0iSStrNmgR OuOtHLuD/d2cTv+/HSF0dEorMen6XQ2seQb5IQYUscEyhDHePKjmMOkpz/1buACk hdDFYSCpRdXyft9Qqg3vl3sU5gnwA3yoBPF5fDqSM6vQrJg6w42cudhNm8EQ9vBM QWD065yrwB9JNyuU6zMEVGyk4uTER3vzViFZkIb+ZfpbbRvDe2/OJw== =qfje -----END PGP SIGNATURE-----
CC: ANDK [...] cpan.org
Subject: Re: [rt.cpan.org #25299] Recursive dependencies
Date: Thu, 15 Mar 2007 22:48:38 +0100
To: bug-Math-BigInt [...] rt.cpan.org
From: andreas.koenig.7os6VVqR [...] franz.ak.mind.de (Andreas J. Koenig)
Download (untitled) / with headers
text/plain 235b
Show quoted text
>>>>> On Thu, 15 Mar 2007 12:51:32 -0400, "nospam-abuse@bloodgate.com via RT" <bug-Math-BigInt@rt.cpan.org> said:
Show quoted text
> [enter endless loop]
Yes. Show quoted text
> Aww crap.
Show quoted text
> Queue v1.81 of BigInt in 10... 9... 8... 7...
Thanks! -- andreas
Should be resolved with the release of v1.81. Thanx for the report!


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.