Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

warn differently about collisions of identical paths #41144

Closed
wants to merge 1 commit into from

Conversation

jerith666
Copy link
Contributor

Motivation for this change

As discussed at https://discourse.nixos.org/t/collisions-between-identical-files/278.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Fits CONTRIBUTING.md.

@@ -110,7 +110,7 @@ sub findFiles {
}

unless (-d $target && ($oldTarget eq "" || -d $oldTarget)) {
if ($ignoreCollisions) {
if ($ignoreCollisions && !checkCollision($oldTarget, $target)) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we also obey checkCollisionContents?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

my reading of the code is that we have three possibilities:

  1. ignore collisions with a warning
  2. silently allow collisions, only if file contents are identical
  3. don't allow any collisions at all

ignoreCollisions tells us if we're in case 1 or not. Then only if not, checkCollisionContents tells us if we're in 2 or 3.

Since all I'm aiming for is silencing meaningless warnings in case 1, I didn't think checkCollisionContents was relevant.

@FRidh
Copy link
Member

FRidh commented May 29, 2018

We should aim at not having duplicate files. These warnings are needed in order to find them and therefore I'm of the opinion we should not silence them.

In your case (https://discourse.nixos.org/t/collisions-between-identical-files/278), an important question to ask is why you actually get multiple versions of Phonon in your profile. This is due to how we package Qt software; all Qt packages get propagated into the profile.

@jerith666
Copy link
Contributor Author

Hm ... would you be open to reporting collisions of identical files differently than collisions of different files? I think they're at least less severe than collisions of different files, right?

@FRidh
Copy link
Member

FRidh commented May 30, 2018

Hm ... would you be open to reporting collisions of identical files differently than collisions of different files? I think they're at least less severe than collisions of different files, right?

It's additional information that could be useful, so if it's cheap to do, yes.

@jerith666
Copy link
Contributor Author

Okay, pushed a new version that still prints a message for identical collisions.

@jerith666 jerith666 changed the title silence warnings about collisions of identical files warn differently about collisions of identical paths Jun 2, 2018
@FRidh
Copy link
Member

FRidh commented Jun 2, 2018

Okay, pushed a new version that still prints a message for identical collisions.

Am I correct that collisions of identical files will now always be printed, and collisions of other files conditionally? That seems a bit weird.

@jerith666
Copy link
Contributor Author

Am I correct that collisions of identical files will now always be printed, and collisions of other files conditionally? That seems a bit weird.

I don't think so, but it's definitely worth talking through before biting off the mass-rebuild:

if we're in the $ignoreCollisions == true case (1st of the three clauses), then we'll always print something -- we just vary the message based on whether the paths are identical.

if we're in the $ignoreCollisions == false case (2nd and 3rd clauses), then we're only silent if the paths are identical (i.e. checkCollision() returns 1 / true). Otherwise, we die. (Well, actually, we unconditionally die if $checkCollisionContents == false.)

I think that's all okay ... ?

@@ -111,7 +111,11 @@ sub findFiles {

unless (-d $target && ($oldTarget eq "" || -d $oldTarget)) {
if ($ignoreCollisions) {
warn "collision between `$target' and `$oldTarget'\n" if $ignoreCollisions == 1;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What I also do not understand about the previous code is, why it checks first for if ($ignoreCollisions) and then has a second check if $ignoreCollisions == 1;. What other states can this variable has?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one stumps me, too. I did a git grep ignoreCollisions, and every place it turned up was setting it to true or false -- in nix expressions. So ... hopefully those translate to 1 and 0 in perl, but I'm not really sure.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Found it:

commit 03f9026ac5ce7568c4b5c28d30552f869e229c63
Author: Eelco Dolstra <eelco.dolstra@logicblox.com>
Date:   Wed Jul 25 16:24:18 2012 -0400

    buildEnv: don't warn about collisions in propagated packages

    This mimicks buildenv in Nix more closely.

diff --git a/pkgs/build-support/buildenv/builder.pl b/pkgs/build-support/buildenv/builder.pl
index 71502c9f668..08331b178f4 100755
--- a/pkgs/build-support/buildenv/builder.pl
+++ b/pkgs/build-support/buildenv/builder.pl
@@ -66,7 +66,7 @@ sub findFiles {

     unless (-d $target && ($oldTarget eq "" || -d $oldTarget)) {
         if ($ignoreCollisions) {
-            warn "collision between `$target' and `$oldTarget'";
+            warn "collision between `$target' and `$oldTarget'" if $ignoreCollisions == 1;
             return;
         } else {
             die "collision between `$target' and `$oldTarget'";
@@ -122,7 +122,7 @@ while (scalar(keys %postponed) > 0) {
     my @pkgDirs = keys %postponed;
     %postponed = ();
     foreach my $pkgDir (sort @pkgDirs) {
-        addPkg($pkgDir, 1);
+        addPkg($pkgDir, 2);
     }
 }

The use of addPkg has changed since 2012, but there's still a case where $ignoreCollisions can be 2. It's on line 198 currently.

Copy link
Contributor

@chreekat chreekat Mar 25, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Therefore I think it makes sense to keep the if $ignoreCollisions == 1 in both cases

edit I mean that it should be refactored so == 1 is always checked, of course. :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be great to have a comment clarifying this.

such collisions are still a concern, but not as severe as collisions
between non-identical paths.
@nixos-discourse
Copy link

This pull request has been mentioned on Nix community. There might be relevant details there:

https://discourse.nixos.org/t/how-to-debug-a-conflict/1524/7

@matthewbauer
Copy link
Member

Looks okay to me... Is there anything left here?

@stale
Copy link

stale bot commented Jun 2, 2020

Thank you for your contributions.
This has been automatically marked as stale because it has had no activity for 180 days.
If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.
Here are suggestions that might help resolve this more quickly:

  1. Search for maintainers and people that previously touched the
    related code and @ mention them in a comment.
  2. Ask on the NixOS Discourse. 3. Ask on the #nixos channel on
    irc.freenode.net.

@stale stale bot added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Jun 2, 2020
@Mic92
Copy link
Member

Mic92 commented Jun 2, 2020

@matthewbauer I think it only needs somebody to test/merge it.

@stale stale bot removed the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Jun 2, 2020
@nixos-discourse
Copy link

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-ready-for-review/3032/431

@stale
Copy link

stale bot commented Jul 8, 2021

I marked this as stale due to inactivity. → More info

@stale stale bot added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Jul 8, 2021
@AndersonTorres
Copy link
Member

Closing as dead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md 10.rebuild-darwin: 501+ 10.rebuild-linux: 501+
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

10 participants