Re: [Fink-devel] pm dependencies
On Monday, Jul 28, 2003, at 12:18 Europe/Brussels, Daniel Macks wrote: I'm not sure I understand, so this paragraph could be irrelevant, but... That sounds like it would mean that every perl I have would have the same modules installed. That might be nice in that no matter which perl I used, I'd have everything present, but that's not always desireable. For large slow-building ones that I only need to use (vs. develop against) and with a simple dependency tree, all I need is *some* version that has it (that's the whole point of unversioned -pm deps). And it's not even always possible (may not work with an old perl, etc.). More importantly, this would mean that building a new perl on one's machine would somehow have to force building of all the -pm that are already existing for other versions for the new one. 1) It are just the 'xyz' pm's that have to be rebuild for a new perl version. Eg, there are only 36 pm580's, out of a total of maybe close to 200 pm's. 2) And in fact, you can still cut this down rather sharply _ to just those among them on which some other unversioned pm you have installed would Depend _ by not installing the corresponding bundle-pm for the others. 3) And if this is still too much _ that you are content to have eg a perl580 for occasional experimenting, and basically 'naked', doing most of your work with some other version _, then just install perl580-core, not perl580, and you're completely free. Consider a package for pure-perl program (that can run under any perl) foo that needs a compiled perl module bar.pm. I really want to have foo: Depends: bar-pm This is exactly what is proposed.. foo.pm remains simple, exactly as you write here, and the 36 or bar-pm's get a dependency scheme ensuring that you will indeed use bar-pmxyz whenever using perlxyz. Hoping this helps to clarify things a bit, Jean-Francois --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] pm dependencies
jfm said: : : There is, if I'm not mistaken, a problem of correct deps : for a multi-perl fink installation. : Recall that some pm's (roughly, those installing a bundle) : must have "Type: Perl x.y.z" in their info file, and be built : with perlx.y.z, to be usable with perlx.y.z _ and those packages : get a name like foo-pmxyz. : If other, non-versioned, pm's have to Depend on those, one : needs an additional package foo-pm (Type: bundle), so the : dependency can get listed as just on foo-pm. : : The problem is how to express correctly the dependency of : foo-pm on the different foo-pmxyz's: the effect should be that : foo-pm being installed is a certificate, for whatever perlx.y.z is : running, that the corresponding foo-pmxyz is there (and not just : some foo-pmx'y'z'). I'm not sure I understand, so this paragraph could be irrelevant, but... That sounds like it would mean that every perl I have would have the same modules installed. That might be nice in that no matter which perl I used, I'd have everything present, but that's not always desireable. For large slow-building ones that I only need to use (vs. develop against) and with a simple dependency tree, all I need is *some* version that has it (that's the whole point of unversioned -pm deps). And it's not even always possible (may not work with an old perl, etc.). More importantly, this would mean that building a new perl on one's machine would somehow have to force building of all the -pm that are already existing for other versions for the new one. This brings up a recent annoyance of mine, though (and it may be a simple rephrasing of the original or else somewhat related or else not at all). The current system seems to require multiple versions of a package to satisfy underlying dependency differences. Consider a package for pure-perl program (that can run under any perl) foo that needs a compiled perl module bar.pm. I really want to have foo: Depends: bar-pm I don't care which perl, so I don't care whether I get bar-pm561 or bar-pm580. But because I could have both perl561 and perl580 concurrently, and bar-pm merely requires "some present perl version" to have bar.pm I need to have foo.info fix #!perl to to point to a perl executable version for which the module is there. Thus I would foo-perl561: Depends: bar-pm561 foo-perl580: Depends: bar-pm580 that install alternatives for bin/foo, and foo: Depends: foo-perl561 | foo-perl580 It feels kinda clunky. And I have to make sure I know whether my depended- on modules are versioned or not (a status which has been known to change, albeit rarely). I'm not sure what if anything can be done, nor even if anything sould be done, but the topic triggered this train of thought:) dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] pm dependencies
On Friday, Jul 25, 2003, at 15:22 Europe/Brussels, jfm wrote: With those, switching back to a previously used version is just doing fink install perlxyz _ the corresponding -not package gets automatically moved out of the way as a conflict, and nothing else has to be done since the deps of all pm's are already satisfied by appropriate pmxyz's, since the version was used before. Sorry, I meant that the (system-)perlxyz packages also have an appropriate Conflict + Replaces for perlxyz-not. (It is probably best not to put a Replaces in perlxyz-not _ wouldn't help there anuway _, in order not to make it too easy for an unwary or curious user to end up with a broken fink. True that he can anywau do "fink remove perlxyz" to the same effect ...) Jean-Francois --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] pm dependencies
On Friday, Jul 25, 2003, at 14:46 Europe/Brussels, David R. Morrison wrote: Hi. This is indeed a tricky problem. Ideally, people might want to have several different versions of the perl-core packages installed, and might want the ability to easily switch back and forth among them. So I am a bit concerned that the "perl-core-not" packages you propose would interfere with this. Hi Dave _ There seems to be a little misunderstanding here : I didn't propose perlx.y.z-core-not packages, but perlx.y.z-not packages. With those, switching back to a previously used version is just doing fink install perlxyz _ the corresponding -not package gets automatically moved out of the way as a conflict, and nothing else has to be done since the deps of all pm's are already satisfied by appropriate pmxyz's, since the version was used before. It is only the install of a new version which is heavier. The distinction is crucial also for the scheme to work at all: remember the "legal path" when doing fink install of a new version , say 580: 1) build perl580 2) install perl580-core 3) build and install in build-order all foo-pm580 for which foo-pm is installed 4) remove perl580_not 5) install perl580 This works because all the (Build)Depends in (3) are _ thanks to you ! _ only on perl580-core. If the package would have been a perl580-core-not , everything would break down: perl580-core cannot be installed w/o removing that, and hence making the deps of all pm-bundles not satisfied. Best, Jean-Francois --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] pm dependencies
Hi. This is indeed a tricky problem. Ideally, people might want to have several different versions of the perl-core packages installed, and might want the ability to easily switch back and forth among them. So I am a bit concerned that the "perl-core-not" packages you propose would interfere with this. However, I also agree that people can end up with a dependency that really doesn't work properly, because the proper x.y.z package for the perl module isn't installed. I hope we could find a solution to this problem that doesn't interfere with easy switching between perl versions, though... -- Dave --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] pm dependencies
There is, if I'm not mistaken, a problem of correct deps for a multi-perl fink installation. Recall that some pm's (roughly, those installing a bundle) must have "Type: Perl x.y.z" in their info file, and be built with perlx.y.z, to be usable with perlx.y.z _ and those packages get a name like foo-pmxyz. If other, non-versioned, pm's have to Depend on those, one needs an additional package foo-pm (Type: bundle), so the dependency can get listed as just on foo-pm. The problem is how to express correctly the dependency of foo-pm on the different foo-pmxyz's: the effect should be that foo-pm being installed is a certificate, for whatever perlx.y.z is running, that the corresponding foo-pmxyz is there (and not just some foo-pmx'y'z'). So here is a proposal: We introduce for each xyz a package 'perlxyz_not' that conflicts with perlxyz (where perlxyz is _ like eg perl580 _ a package that basically just does "ln -fs `which perlx.y.z`%p/bin/perl" _ hence conflicts with all other perlx'y'z') and with system-perlxyz: then we can let all foo-pm depend on " perlxyz_not | foo-pmxyz " for all xyz. This will require the user to install foo-pmxyz for all bundles foo-pm and all perl versions x.y.z he has installed _ but there are not that many bundles, and it seems a condition for a reliable system. Note that the 'perlxyz_not' packages are not logically necessary in this proposal, they are just a shorthand to simplify the writing of the Deps in the foo-pm packages : else each 'perlxyz_not' in those Deps should be replaced by the alternative that some other perlx'y'z' is installed. The system has some defects: eg, a user who would not install perlxyz, just perlxyz-core, and try to use that _ either by using explicitly "perlx.y.z" as command or by doing "ln -s `which perlx.y.z`/usr/local/bin/perl" would not be protected. Also, I'm afraid manual intervention will be required eg when a user, who has nothing of say perl580 installed, and hence has perl580_not installed, issues 'fink install perl580' : the logic is that - since the user explicitly asks to install a package that conflicts with perl580_not, the latter package will have to go. - since there is a legal way to satisfy the user's request without removing any other package, that's what should be done [ The legal way: 1) build perl580 2) install perl580-core 3) build and install in build-order all foo-pm580 for which foo-pm is installed 4) remove perl580_not 5) install perl580 ] But I don't think fink or dpkg's dependency engines are capable of this (maybe apt-get ?), and some manual guidance will be required here.. Comments ? Improvements or other suggestions ? Jean-Francois Mertens --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
