Re: Conflicts in the meta spec
On 4/15/13 7:02 PM, Mike Doherty wrote: > This requires Moose maintainers to know about all the things their > releases break. Have you considered reversing the directionality so > MooseX::Blah knows about the things which break it? That seems like a > more likely scenario to me, and lets the right maintainer control the > "conflicts" relationship. It's a good idea to reverse the relationship. In this case it doesn't work out. * I believe that was the confusion at the Lancaster Consensus, that conflict was a way to express "I can use Parent >= 1.23 but not 1.69". That is already covered by the "requires" relationship and version ranges. requires: Parent: >= 1.23, != 1.69 * In order to find out what modules Parent conflicts with, necessary when installing Parent, a CPAN shell would have to iterate through every module's metadata. [1] * Parent can test its dependents before Parent releases, but Child cannot. Parent has the opportunity to test and mark its conflicts at release time so at least CPAN shells can protect users of Child from upgrading Parent and breaking Child. [2] [1] It would be nice if we had a reliable meta API for that, but we don't at the moment. [2] This should contain the assumption "in an automated fashion". Sure, Parent and Child can keep in close communication with each other, but this does not scale. When you're a heavily depended on module such as File::Spec, Test::More, Moose, DBIx::Class, Module::Build, ExtUtils::MakeMaker or version you simply have too many dependents and are too many levels removed.
Re: Conflicts in the meta spec
On Mon, Apr 15, 2013 at 11:02 AM, Mike Doherty wrote: > On 13-04-15 01:56 PM, Michael G. Schwern wrote: >> >> Why we need this, why you can't do it with "requires" is because this is >> for modules which you do not depend on. Often they depend on you. >> MooseX::Blah depends on Moose, so Moose declares conflict with versions >> of MooseX::Blah it breaks. > > > This requires Moose maintainers to know about all the things their releases > break. Have you considered reversing the directionality so MooseX::Blah > knows about the things which break it? That seems like a more likely > scenario to me, and lets the right maintainer control the "conflicts" > relationship. Ideally, you would have this information in both locations, as users can install in either sequence: 1) New install: MooseX::Blah requires Moose, so Moose will install first. Moose cannot warn because MooseX::Blah isn't installed yet. So MooseX::Blah needs to warn during installation. 2) Older version of Moose and latest version of MooseX::Blah already installed. User updates Moose. Moose should warn that it will break already installed MooseX::Blah. I've run into this scenario with DBI and DBD::AnyData before, where only DBI warns about the conflict, but DBD::AnyData doesn't: https://rt.cpan.org/Public/Bug/Display.html?id=83293 Cheers, -Jan
Re: Conflicts in the meta spec
On 13-04-15 01:56 PM, Michael G. Schwern wrote: Why we need this, why you can't do it with "requires" is because this is for modules which you do not depend on. Often they depend on you. MooseX::Blah depends on Moose, so Moose declares conflict with versions of MooseX::Blah it breaks. This requires Moose maintainers to know about all the things their releases break. Have you considered reversing the directionality so MooseX::Blah knows about the things which break it? That seems like a more likely scenario to me, and lets the right maintainer control the "conflicts" relationship. -Mike
Re: Test::Builder, MakeMaker & Consensus QA Hackathon Achievements
On 04/15/2013 12:20 PM, Michael G. Schwern wrote: > I've just updated the wiki with the achievements around the projects I > was associated with. I'll paste them below. > http://2013.qa-hackathon.org/qa2013/wiki?node=Achievements Thanks to all the Hackathon contributors for these updates! As a CPAN author and user, I appreciate the work on all these behind-the-scenes updates. Mark
Conflicts in the meta spec
TL;DR version... IMO we only need to clarify what "conflicts" means and what actions CPAN tools should take. We talked in the Consensus Dome about the need for and meaning of the "conflicts" relationship in the CPAN::Meta::Spec. https://metacpan.org/module/CPAN::Meta::Spec#Prereq-Spec IIRC the conclusion was... * We need it. * It's not clear what it means. (I don't recall what the confusion was) * Let's see what Debian does. I can come up with a few situations where being able to declare conflicts with other packages would have (and will be) very useful. Mostly in the "if you install Foo version 1.23 then your previously installed Bar version 2.34 will break". * Moose vs MooseX * Test::Harness 2 and 3 broke a few modules * Test::Builder 1.5 vs Test::Class, Test::Most, Test::Random... * Module::Install vs its plugins Why we need this, why you can't do it with "requires" is because this is for modules which you do not depend on. Often they depend on you. MooseX::Blah depends on Moose, so Moose declares conflict with versions of MooseX::Blah it breaks. IMO CPAN shells can take several actions on a conflict... * Warn the user * Upgrade the conflicting modules (if possible) * Refuse to install the new version if non-conflicting upgrades are not available Debian has several fields to deal with this, "Breaks", "Conflicts" and "Replaces". http://www.debian.org/doc/debian-policy/ch-relationships.html#s-breaks http://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces We may not need them all. Here's a summary. Breaks -- When one binary package declares that it breaks another, dpkg will refuse to allow the package which declares Breaks to be unpacked unless the broken package is deconfigured first, and it will refuse to allow the broken package to be reconfigured. Conflicts - When one binary package declares a conflict with another using a Conflicts field, dpkg will refuse to allow them to be unpacked on the system at the same time. This is a stronger restriction than Breaks, which prevents the broken package from being configured while the breaking package is in the "Unpacked" state but allows both packages to be unpacked at the same time. If one package is to be unpacked, the other must be removed first. Replaces Packages can declare in their control file that they should overwrite files in certain other packages, or completely replace other packages. It is usually an error for a package to contain files which are on the system in another package. However, if the overwriting package declares that it Replaces the one containing the file being overwritten, then dpkg will replace the file from the old package with that from the new. Second, Replaces allows the packaging system to resolve which package should be removed when there is a conflict. This usage only takes effect when the two packages do conflict, so that the two usages of this field do not interfere with each other. === "Breaks" vs "Conflicts" is only about at what phase they conflict. We have that covered with prereq phases. # Declare that Test-Simple 1.5.0 will break Test::Class <= 0.38 name: Test-Simple version: 1.5.0 prereq: runtime: conflicts: Test::Class: <= 0.38 It seems pretty clear from the Debian manual that when two things conflict it means they cannot be installed at the same time. That to me seems the correct reading and covers our use cases. I don't think "Replaces" yet simply because we don't have a clear concept of a distribution. For example, you'd use Replaces to say "LWP replaces libwwwperl" but we don't understand that yet. It might be more useful when we have the installed distributions database. We also have no concept of virtual packages, which means we can't say "Apache replaces http-server". Maybe we can do it at the package name level, but I don't see there is a concrete need.
Test::Builder, MakeMaker & Consensus QA Hackathon Achievements
I've just updated the wiki with the achievements around the projects I was associated with. I'll paste them below. http://2013.qa-hackathon.org/qa2013/wiki?node=Achievements In addition I fleshed out the Lancaster Consensus conclusions according to my photographs of the white board and my own recollections because it was looking a bit sparse. Apologies if I got anything wrong, please correct and fill in. And Wendy, please consider your own notes canonical. Test::Builder 1.5 - A small team worked through the roughly 100 of 700 Test-* distributions failing with Test::Builder 1.5 alpha but passing with the current 0.98 stable. Verify it's failing with 1.5 and passing with 0.98 Verify it's because of a Test::Builder 1.5 change Categorize the failure type Patch either Test::Builder or the module as appropriate If the module runtime had to be patched, note it as a conflict. We did the work primarily on an EtherPad and in the Test-More Github issue tracker by a small team of remote and local developers. Karen Ethridge (ether) James Mastros (theorbtwo) Colin Newell Daniel Perrett (pdl) Michael G Schwern (schwern) Nearly all the modules got looked at, and a number patched. Other accomplishments by the team... Determined that rolling back the TAP formatting changes in 1.5 will not significantly help Fixed Test::More stable and 1.5 alpha for 5.17. Released 0.98_04 and 1.5.0_6 Improved the script for testing CPAN modules with stable vs alpha. Fixed the 1.5 alpha under taint mode Fixed the 1.5 alpha on Windows Misc documentation updates Got a new release of Test::Class working with 1.5 ExtUtils::MakeMaker stable release -- Chris Williams (BingOS) stepped up to manage the next stable release of ExtUtils::MakeMaker to be in time for Perl 5.18.0 and released several alphas. They will be very well tested. :)
