----- "Dave Cross" <dave@xxxxxxxxxxx> wrote: > On 02/09/2010 08:10 AM, Ralf Corsepius wrote: > > On 02/08/2010 06:10 PM, Gabor Szabo wrote: > >> Hi, > >> > >> I saw these bug reports starting to flow in two days ago, > >> just in time to mention them during my talk on FOSDEM. > >> > >> The problem seems to be that the rpm builder extracted the list of > >> dependencies of Padre from its source code. This did not notice > that > >> Win32::API is use only when running on Windows and thus it was > >> included in the list of dependencies. > >> > >> The right way would be to use the list of dependencies as supplied > in > >> the META.yml file in the Padre tarbal. > >> > >> Dave Cross blogged about this probably explaining in a much better > way > >> than I did: > >> > http://perlhacks.com/2010/02/building-rpms-from-cpan-distributions.php > > > > Though I partially agree with Dave on his "rpm does something > > brain-dead" statement, I think his reasoning suffers from a thinko: > > > > <cite> > > And that's, of course, where the RPM builders should be going to get > a > > list of dependencies. META.yml contains the list of other modules > that > > the author wants the module to depend on. This should be seen as the > > > definitive list. Of course, there might be errors in that list - but > > > that should be addressed by raising a bug against the module. > > </cite> > > > > IMO, he misses that what a perl-module's author thinks he wants "his > > > module to depend on" is largely irrelevant to Fedora. > > What is relevant to Fedora, is "what the module actually uses" and > what > > we _want_ it to actually use. > > > > > > These sets overlap, but ... they are not identical. > > > > Example: Putting bugs in Meta.yml aside (they are not so uncommon as > > > people might believe), a classical corner-case in rpm-packaging > > perl-modules are "Perl required'ed modules" (i.e. optional > modules). > > If a module is optional, then it's not required and shouldn't be > listed > as a dependency. Do you have an example that illustrates your point? Quite often is missing build requirements for modules e.g. Test::More, but I can't think of any package now. > > Going back to the Plack example I used in my blog post. There are a > huge > number of modules that Plack can make use of it they are installed on > your system. But if they aren't, Plack will still work fine - but it > may > be that some functions won't be available. If, however, you > subsequently > install the missing modules, this functions become available to you. > > In my opinion, these modules are not essential and shouldn't be > listed > as dependencies. I suspect this is where our philosophical > differences > will lie. > > > To us, they often are not optional, but mandatory (rpm's > "Requires:"), > > because rpm doesn't have a concept of "optional requires". > > META.yaml has Requires and BuildRequires lines. These map directly > onto > the same concepts in RPM. META.yml also has a (little-used) > Recommends > lines. I don't think RPM has a concept like that. > No, rpm is missing so-called soft-dependencies and it is on decision of packager. > I can think of two corner cases where META.yml doesn't (yet) do the > right thing. > > 1/ There are cases where certain modules are required in certain > circumstances. For example, Padre needs Win32::API if it's running on > Windows. META.yml doesn't have a way to model those kinds of > "optional > dependencies". > > 2/ Some modules require any one from a set of dependencies. For > example > JSON::Any requires one from the list JSON::XS, JSON and JSON::DWIW. > Clearly, each system only needs one of those installed, but you can't > list any of them as a dependency. And even if you could, would RPM > support this model? > > So yes, there are still a few issues with META.yml. But, in general, > I > think it gives a better starting point than the current behaviour of > looking for all of the "use" (and "require") statements. > > > Finally: I question your claim of "META.yml" to be always right. > > I know that META.yml isn't always going to be right. But when it > isn't, > that should be treated as a bug in the upstream distribution and > reported back to the author - perhaps including a patch. > > (Yes, this opens a whole new can of worms about unresponsive or > missing > CPAN authors. This is something that the Perl community is aware of > and > is planning to address.) > > Cheers, > > Dave... > -- > Fedora Extras Perl SIG > http://www.fedoraproject.org/wiki/Extras/SIGs/Perl > perl-devel mailing list > perl-devel@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/perl-devel -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/perl-devel
