Re: [Fink-devel] The perl modules situation, revisited
On Mon, Apr 12, 2004 at 01:36:48PM -0400, David R. Morrison wrote: > > How will we handle such provides from system-perl done in the virtuals? > > Excellent question! Can we easily get fink to think that the virtual > system-perl has provided certain things? Absolutely! There are already a number of "provides" in the virtual packages (and some are mentioned in the brand-spankin'-new virtpackage FAQ). It's just a matter of editing VirtPackage.pm. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] The perl modules situation, revisited
> How will we handle such provides from system-perl done in the virtuals? Excellent question! Can we easily get fink to think that the virtual system-perl has provided certain things? If so, I can create a list of the appropriate Provides... -- Dave --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] The perl modules situation, revisited
P.S. I forgot to say: a couple of the packages which Patrick identified have not been moved forward from 10.2 to 10.3. Since my focus at the moment is to get things working in 10.3, I ignored those packages (for now). Most likely, they are not too crucial for 10.3 since we have lived without them for nearly six months. -- Dave --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] The perl modules situation, revisited
David R. Morrison wrote: In my experimental/dmrrsn/perlmods directory, I have placed experimental new versions of perl560, perl580, and perl583. All of the perl* packages except perl580 now contain an extensive list of "Provides", which will allow us just put things like "Depends: file-spec-pm" instead of having to say "file-spec-pm | perl580-core | perl583-core". These perl* packages also have a large number of "Replaces", to take care of duplicate files in /sw/bin and /sw/share/man. How will we handle such provides from system-perl done in the virtuals? -- Benjamin Reed, a.k.a. RangerRick [EMAIL PROTECTED] / http://ranger.befunk.com/ --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] The perl modules situation, revisited
Whoops, typo: "except perl580" should have been "except perl560" in the previous message... it's the perl560 package which doesn't need to "Provide" other things... -- Dave --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] The perl modules situation, revisited
Patrick Näf was kind enough to compile lots of information about perl module conflicts in late February, and I am now acting on this. (His message is reproduced below.) In my experimental/dmrrsn/perlmods directory, I have placed experimental new versions of perl560, perl580, and perl583. All of the perl* packages except perl580 now contain an extensive list of "Provides", which will allow us just put things like "Depends: file-spec-pm" instead of having to say "file-spec-pm | perl580-core | perl583-core". These perl* packages also have a large number of "Replaces", to take care of duplicate files in /sw/bin and /sw/share/man. At the same time, I started to implement the new policy about -pm files, as explained in my previous message. Comments about this are welcome. -- Dave =?ISO-8859-1?Q?Patrick_N=E4f?= <[EMAIL PROTECTED]> wrote: > First off, if you think that this really unimportant stuff, please don't > hesitate to ignore this message :-) > > > A couple of months ago there was a discussion about perl modules that > exist in 2 versions: > > 1) as standalone packages > 2) inside the perl580 package > > The problem discussed was that some of these modules, when installed as > their own package, might conflict with the perl580 package. > > Based on JFM's suggestions (see > http://www.mail-archive.com/[EMAIL PROTECTED]/ > msg07481.html) > I had a look at the 20-some packages that he mentioned. I tried to find > out whether the packages have conflicts with perl580 at all, and if they > have, what the differences between the conflicting files are. > > Since I'm not entirely sure what to do with the results, I send them to > the list (cc to the respective maintainers) and hope for your comments. > > In all cases, the only conflicting files were man page files in > /sw/share/man/man3. > > There are 3 result categories: > 1) the package does not have any conflicts with perl580 > 2) the package has conflicts, but the conflicting man page files seem to > be virtually the same > 3) the package has conflicts, the conflicting man page files are > significantly different > > Again, based on how I understand JFM's comments, I suggest that we do > the following for each category: > 1) leave everything as is > 2) even though it's not strictly necessary, just to avoid confusion, > add a > "Replaces:" field to the standalone module .info and the perl580.info > files > 3) the same as 2), but here the "Replaces:" field is really necessary > > > Please comment. If I should examine additional modules, I'll be pleased > to do so. Whatever we agree on, we should then proceed to make all > the changes to perl580.info in one fell swoop :-). That's the main > reason > for this message... > > Cheers > Patrick > > > Here are the results, sorted by maintainer, result type and > package (including version/revision that I had on my system). > I have enabled the 10.2-gcc3.3 tree. > > Christian Schaffner > - no conflicts: >- attribute-handlers-pm (0.78-2) >- cgi-pm (3.00-1) >- file-temp-pm (0.12-2) >- i18n-langtags-pm (0.28-2) >- locale-maketext-pm (1.06-1) >- template-pm (2.10-1) >- time-hires-pm (1.51-1) > > Dave Morrison > - no conflicts: >- digest-md5-pm (2.24-3) > > Fink Core Group > - conflicts with significant differences >- file-spec-pm (0.82-1) >- storable-pm (1.0.14-6) > > Jeffrey Whitaker > - no conflicts: >- filter-util-pm (1.26-3) > - conflicts with significant differences >- filter-simple-pm (0.77-1) > > No maintainer > - no conflicts: >- mime-base64-pm (2.18-3) >- scalar-list-utils-pm (1.11-3) > - conflicts without significant differences >- getopt-long-pm (2.32-19) >- libnet-pm (1.13-11) >- test-harness-pm (2.26-2) > - conflicts with significant differences >- memoize-pm (0.66-2) >- test-simple-pm (0.47-1) > > Patrick Näf (myself) > - conflicts without significant differences >- text-tabs-wrap-pm (2001.0929-1) > --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] The perl modules situation, revisited
First off, if you think that this really unimportant stuff, please don't hesitate to ignore this message :-) A couple of months ago there was a discussion about perl modules that exist in 2 versions: 1) as standalone packages 2) inside the perl580 package The problem discussed was that some of these modules, when installed as their own package, might conflict with the perl580 package. Based on JFM's suggestions (see http://www.mail-archive.com/[EMAIL PROTECTED]/ msg07481.html) I had a look at the 20-some packages that he mentioned. I tried to find out whether the packages have conflicts with perl580 at all, and if they have, what the differences between the conflicting files are. Since I'm not entirely sure what to do with the results, I send them to the list (cc to the respective maintainers) and hope for your comments. In all cases, the only conflicting files were man page files in /sw/share/man/man3. There are 3 result categories: 1) the package does not have any conflicts with perl580 2) the package has conflicts, but the conflicting man page files seem to be virtually the same 3) the package has conflicts, the conflicting man page files are significantly different Again, based on how I understand JFM's comments, I suggest that we do the following for each category: 1) leave everything as is 2) even though it's not strictly necessary, just to avoid confusion, add a "Replaces:" field to the standalone module .info and the perl580.info files 3) the same as 2), but here the "Replaces:" field is really necessary Please comment. If I should examine additional modules, I'll be pleased to do so. Whatever we agree on, we should then proceed to make all the changes to perl580.info in one fell swoop :-). That's the main reason for this message... Cheers Patrick Here are the results, sorted by maintainer, result type and package (including version/revision that I had on my system). I have enabled the 10.2-gcc3.3 tree. Christian Schaffner - no conflicts: - attribute-handlers-pm (0.78-2) - cgi-pm (3.00-1) - file-temp-pm (0.12-2) - i18n-langtags-pm (0.28-2) - locale-maketext-pm (1.06-1) - template-pm (2.10-1) - time-hires-pm (1.51-1) Dave Morrison - no conflicts: - digest-md5-pm (2.24-3) Fink Core Group - conflicts with significant differences - file-spec-pm (0.82-1) - storable-pm (1.0.14-6) Jeffrey Whitaker - no conflicts: - filter-util-pm (1.26-3) - conflicts with significant differences - filter-simple-pm (0.77-1) No maintainer - no conflicts: - mime-base64-pm (2.18-3) - scalar-list-utils-pm (1.11-3) - conflicts without significant differences - getopt-long-pm (2.32-19) - libnet-pm (1.13-11) - test-harness-pm (2.26-2) - conflicts with significant differences - memoize-pm (0.66-2) - test-simple-pm (0.47-1) Patrick Näf (myself) - conflicts without significant differences - text-tabs-wrap-pm (2001.0929-1) --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56&alloc_id438&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] The perl modules situation
On Dec 24, 2003, at 9:37 PM, David R. Morrison wrote: My belief is that the "Provides" line is not enough to satisfy dpkg. Certainly that was true in the early days of fink. It's possible that it has changed, and that I haven't kept up with dpkg's capabilities. I'm not talking about adding Provides lines to the virtual perl packages, i'm talking about adding whole new virtual packages for every perl module a fink user has in the system perl. To fink, dpkg, and apt, VirtPackages.pm creates real packages, not "Provides". It all works because of our hack to dpkg and apt. If a user tries to install something that wants cctools (>= 446-1), it works fine - the install fails until they install the new dev tools. The proposed perl modules solution should work too. http://sourceforge.net/tracker/index.php? func=detail&aid=865568&group_id=17203&atid=367203 -Ben --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] The perl modules situation
Ben Hines <[EMAIL PROTECTED]> wrote: > On Dec 11, 2003, at 5:38 AM, David R. Morrison wrote: > > > > > The obvious solution to this problem would be to use versioned Provides > > statements. That is, if you installed perl581 (or the virtual > > system-perl581), > > you would get > > > > You seem to misunderstand my issue. We already have versioned provides. > The virtpkgs.pm pseudo package provides are all versioned. There is no > issue, the .pm and dpkg/apt simply need to be fixed to provide the > packages, just like they provide certain versions of cctools and perl. > > -Ben > In any package, virtual or not, you can say something like Provides: xfree86 (>= 4.3-1) The question is, if a different package says Depends: xfree86 (>= 4.3-1) will that dependency be satisifed by the "Provides" line, or will it only be satisfied by an actual xfree86 package with the correct version number? This is a question of the behavior of dpkg/apt, not of fink, since we use dpkg and apt to manage the final steps of our installations (and to keep track of dependency information like this). My belief is that the "Provides" line is not enough to satisfy dpkg. Certainly that was true in the early days of fink. It's possible that it has changed, and that I haven't kept up with dpkg's capabilities. -- Dave --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] The perl modules situation
On Dec 11, 2003, at 5:38 AM, David R. Morrison wrote: The obvious solution to this problem would be to use versioned Provides statements. That is, if you installed perl581 (or the virtual system-perl581), you would get You seem to misunderstand my issue. We already have versioned provides. The virtpkgs.pm pseudo package provides are all versioned. There is no issue, the .pm and dpkg/apt simply need to be fixed to provide the packages, just like they provide certain versions of cctools and perl. -Ben --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] The perl modules situation
jfm said: > Typically perl580 (eg) will install the same man pages, at the same > place. > So in order for the user not to have to force-overwrites , yes, you > need such > a Replaces (and perl580 too) _ if this is the case with your package. Ah, I see, the whole business is about the man pages - I didn't catch that earlier. > In that case, make sure that your package is at least as up to date as > the one in > perl580 _ and that the corresponding man pages are substantially the > same I'll do that then, thanks for the instruction. Patrick --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] The perl modules situation
I'm afraid I've still been too sketchy, and it is not that easy _ because the perlxyz (say 580) packages need such a Replaces too, and it seems out of the question to have to update (including rev-up) this every time a maintainer of one of those +/- 20 packages checks his own _ this has to be centralized a bit one way or the other. Maybe you would be willing to do this, and then coordinate with the maintainer of perl580 ? An old list of pkgs to look at follows in PS (give and take one..). OK, I'll do it. Although I might need some help if I have to make a decision about a package that conflicts with something else than just man pages, esp. when the files in question bear some functionality. I'll take your list of packages as my working basis, if somebody wishes to add to or remove from the list, please feel free. Cheers Patrick -- Patrick Naef"The Queen of Hearts, she made some tarts, Kriens, Switzerland All on a summer day: [EMAIL PROTECTED]The Knave of Hearts, he stole those tarts, PGP public key: And took them quite away!" http://www.herzbube.ch/Misc/PGPHerzbubeAtHerzbubeDotCH.txt --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] The perl modules situation
On Dec 15, 2003, at 8:39 AM, Patrick Näf wrote: jfm said: Typically perl580 (eg) will install the same man pages, at the same place. So in order for the user not to have to force-overwrites , yes, you need such a Replaces (and perl580 too) _ if this is the case with your package. Ah, I see, the whole business is about the man pages - I didn't catch that earlier. In that case, make sure that your package is at least as up to date as the one in perl580 _ and that the corresponding man pages are substantially the same I'll do that then, thanks for the instruction. I'm afraid I've still been too sketchy, and it is not that easy _ because the perlxyz (say 580) packages need such a Replaces too, and it seems out of the question to have to update (including rev-up) this every time a maintainer of one of those +/- 20 packages checks his own _ this has to be centralized a bit one way or the other. Maybe you would be willing to do this, and then coordinate with the maintainer of perl580 ? An old list of pkgs to look at follows in PS (give and take one..). Basically, it involves installing perl580, then building each of those pkgs and installing them with dpkg --force-overwrites, so as to see the exact set of files that would get replaced, then checking for each of those files (I would expect mainly man files, but if I remember correctly there may also be sometimes scripts in /sw/bin, where obviously much more caution is required) whether it agrees substantially (ie, conveys exactly the same infomation) with the one of perl580. (Eg, by extracting also perl580 in a tmp dir, and doing, for each file, 'man full_path_to_man_file' to each of the 2 man files in 2 parallel windows). JF Mertens PS: attribute-handlers-pm cgi-pm digest-md5-pm file-spec-pm file-temp-pm filter-simple-pm filter-util-pm getopt-long-pm i18n-langtags-pm libnet-pm locale-maketext-pm memoize-pm mime-base64-pm scalar-list-utils-pm storable-pm template-pm test-harness-pm test-simple-pm text-tabs-wrap-pm time-hires-pm --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] The perl modules situation
On Dec 14, 2003, at 12:38 AM, Patrick Näf wrote: I'm the owner of one of the modules which is provided by perl580 (text-tabs-wrap-pm). When JFM brought this up back in August he suggested that, "appropriate 'Replaces' fields be put in those packages, and in perl580." JFMs suggestion can't really mean that I have to put Replaces: perl580 into my package, can it? Typically perl580 (eg) will install the same man pages, at the same place. So in order for the user not to have to force-overwrites , yes, you need such a Replaces (and perl580 too) _ if this is the case with your package. In that case, make sure that your package is at least as up to date as the one in perl580 _ and that the corresponding man pages are substantially the same (else you would have to resort to update-alternatives, which is much heavier, and I guess often forgotten by the user) Best, Jean-Francois --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] The perl modules situation
Am Donnerstag, 11.12.03, um 14:38 Uhr (Europe/Zurich) schrieb David R. Morrison: Ben Hines has again raised the issue of how we handle perl modules which are provided by newer versions of perl, but were not provided by older versions of perl. This has been brought up before by JF Mertens. I'm the owner of one of the modules which is provided by perl580 (text-tabs-wrap-pm). When JFM brought this up back in August he suggested that, "appropriate 'Replaces' fields be put in those packages, and in perl580." I didn't do anything to my package in August, and I forgot to do so since then. Now that you remind me of it, I think it would be a good time to finally correct the flaw in my package. Unfortunately, I find that I don't really understand what I have to do - stupid me :-( JFMs suggestion can't really mean that I have to put Replaces: perl580 into my package, can it? Any enlightenment would be welcome Patrick -- Patrick Naef"The Queen of Hearts, she made some tarts, Kriens, Switzerland All on a summer day: [EMAIL PROTECTED]The Knave of Hearts, he stole those tarts, PGP public key: And took them quite away!" http://www.herzbube.ch/Misc/PGPHerzbubeAtHerzbubeDotCH.txt --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] The perl modules situation
Ben Hines has again raised the issue of how we handle perl modules which are provided by newer versions of perl, but were not provided by older versions of perl. This has been brought up before by JF Mertens. Each release of perl incorporates some new perl modules into the release, and in addition updates the versions of some of the existing modules. On the other hand, many of those modules continue to be under active development, and someone may need a more recent version of the module than was provided by the most recent release of perl. The obvious solution to this problem would be to use versioned Provides statements. That is, if you installed perl581 (or the virtual system-perl581), you would get Provides: digest-md5-pm (= 2.27-1) while if you installed perl580 you would get Provides: digest-md5-pm (= 2.20-1) and earlier versions would not provide this package at all. However, as far as I know, dpkg and apt-get do not recognize versioned Provides. So we can't use this system at the moment. Hopefully, somebody will get interested in the task of revising our tools to allow versioned Provides. (I'll comment more about why it would be bad to use non-versioned Provides at the end of this message.) What we could do for now, though, is to make some better documentation about what versions of which perl module packages are provided by the different flavors of perl. A place to start, if anybody wants to work on this, is: http://search.cpan.org/~jhi/perl-5.8.0/ and the related pages which are linked from there. -- Dave P.S. Here's why it would be bad to use non-versioned Provides. Of course, we can add "Provides: digest-md5-pm" to the perl580 and perl581 packages. Suppose package foo then needs a new feature which is contained in v.2.30 of digest-md5-pm. Then package foo will have to say "Depends: digest-md5-pm (>= 2.30-1)" which also is no problem. However, if perl583 is later released and it contains version 2.30 of digest-md5-pm, there will be no way to remove the versioned depedency from package foo. That is, you'll have to live with "Depends: perl583-core | digest-md5-pm (>= 2.30-1)" forever (even if we later get a versioned Provides implemented). Thus, using non-versioned Provides would give only a short-term solution to this problem, and it would prevent us from ever implementing the long-term solution of versioned Provides. --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
