QA checks for package directory net-misc/nxserver-enterprise: net-misc/nxserver-enterprise: digest collisions: major: Digest conflict on 'nxserver-1.3.0-25.i386.rpm' in 'net-misc/nxserver-enterprise/files/digest-nxserver-enterprise-1.3.0-r2' (original was 'net-misc/nxserver-business/files/digest-nxserver-business-1.3.0-r2') major: Digest conflict on 'nxserver-1.3.2-25.i386.rpm' in 'net-misc/nxserver-enterprise/files/digest-nxserver-enterprise-1.3.2' (original was 'net-misc/nxserver-business/files/digest-nxserver-business-1.3.2') major: Digest conflict on 'nxserver-1.3.2-25.i386.rpm' in 'net-misc/nxserver-enterprise/files/digest-nxserver-enterprise-1.3.2-r1' (original was 'net-misc/nxserver-business/files/digest-nxserver-business-1.3.2') major: Digest conflict on 'nxserver-1.4.0-107.i386.rpm' in 'net-misc/nxserver-enterprise/files/digest-nxserver-enterprise-1.4.0' (original was 'net-misc/nxserver-business/files/digest-nxserver-business-1.4.0') QA checks for package directory net-misc/nxserver-personal: net-misc/nxserver-personal: digest collisions: major: Digest conflict on 'nxserver-1.3.0-25.i386.rpm' in 'net-misc/nxserver-personal/files/digest-nxserver-personal-1.3.0-r2' (original was 'net-misc/nxserver-business/files/digest-nxserver-business-1.3.0-r2') major: Digest conflict on 'nxserver-1.3.2-25.i386.rpm' in 'net-misc/nxserver-personal/files/digest-nxserver-personal-1.3.2' (original was 'net-misc/nxserver-business/files/digest-nxserver-business-1.3.2') major: Digest conflict on 'nxserver-1.3.2-25.i386.rpm' in 'net-misc/nxserver-personal/files/digest-nxserver-personal-1.3.2-r1' (original was 'net-misc/nxserver-business/files/digest-nxserver-business-1.3.2') major: Digest conflict on 'nxserver-1.4.0-107.i386.rpm' in 'net-misc/nxserver-personal/files/digest-nxserver-personal-1.4.0-r2' (original was 'net-misc/nxserver-business/files/digest-nxserver-business-1.4.0') major: Digest conflict on 'nxserver-1.4.0-107.i386.rpm' in 'net-misc/nxserver-personal/files/digest-nxserver-personal-1.4.0-r3' (original was 'net-misc/nxserver-business/files/digest-nxserver-business-1.4.0') File name collisions or duff digests?
Upstream filename collisions. Talked to them, but had no luck in getting them to change their release policy. Does your test strategy take the different SRC_URI's into account, from the different ebuilds? This would reduce the false positives in this case. Best regards, Stu
Stu, This bug is still valid. Please put a versioned file in the tree.
Why? Best regards, Stu
As it stands, anyone who tries to install one of the listed packages, then (optionally) unmerges it, then installs a different listed package, will get a huge flashy security violation error because a file with the same name but a different digest will already be present in distfiles/.
I know. It's been that way since day one. But ... this is a commercial application, which we do not have the right to redistribute (all the ebuilds are marked 'nomirror'). I don't believe we have the legal right to do what you ask, sorry. Best regards, Stu
Then the package cannot be in the tree.
Sorry, but to the best of my knowledge, that's not a decision you (the QA team) are empowered to make. If there's a policy doc somewhere that says otherwise, please let me know, and I'll happily re-open the bug. Best regards, Stu
(In reply to comment #7) > Sorry, but to the best of my knowledge, that's not a decision you (the QA team) > are empowered to make. If there's a policy doc somewhere that says otherwise, > please let me know, and I'll happily re-open the bug. Actually, this is exactly what the QA team has a say on. If we can't fix it, it has to go.
Then you'll have no trouble providing a reference to the policy document that supports that statement, as requested. Until then, please stop re-opening this bug. Best regards, Stu
http://marc.theaimsgroup.com/?l=gentoo-dev&m=114079105218215&w=2 There you go.
Sorry, but that's not an official policy document empowering the QA team to demand that packages are removed from Portage. Best regards, Stu
Please point me to the official policy document that explicitly states that you (mentioned by name) are allowed to add packages to the tree. The number one rule for the tree is to be sensible. It's impossible to document every single thing that could ever happen. Instead, you're expected to understand what you're doing and not take actions that lead to breakage. A breakage has been pointed out here, and you have been asked to fix it. If you're not prepared to fix it, QA will have to consider fixing it for you, and we don't want to have to do this to anyone except as a last resort.
Touche :) All I'm after is being sensible too. Your automated checking tool has pointed you to a problem that you (the QA team) haven't noticed before now. These packages have been in the tree over two years, and *now* they're a problem? :) These are commercial packages that people pay money for. They are not mirrored. A user would have to buy two or more editions of the same version of these packages, and would have to install them on the same box for the problem to occur. I've just searched bugzilla, and in two and a half years, there doesn't seem to be a single bug raised about this problem from users. C'mon, be sensible here. If you can't see that there isn't a practical problem here, and insist on the packages being removed, then I've no choice but to tell you to leave this alone until you can provide a official mandate empowering you to do anything. I'd expect you to do the same if the roles were reversed. Now please, until this has gone before the council, or you find that policy document, leave it at that. Best regards, Stu
Please leave this bug open till it has had a chance to be reviewed by all of the council then. Also please send mail with your intentions to have this reviewed by the council at least one week in advance. Tentative date for the next meeting is March 9, 2006
To solve this issue, since !M named the different server versions the same thing, I think it might be possible to use a package format for each of the versions. They offer three package formats: .rpm, .deb, and .tar.gz. nxserver-personal could use the .rpm nxserver-business could use the .tar.gz nxserver-enterprise could use the .deb This would affectively give each server version a different filename. They only differ by the extension, but that's enough to pass the digests. Would this be a good solution? Would this be allowed, since it is using a .deb file. I have the ebuilds done, but not tested well do to little time. But, things like binary compatibility needs to be tested, but if this works, would this pass QA? If not, then we need to think of something else. Thanks.
Best/easiest/cleanest solution that I've seen mentioned somewhere is to fetch restrict the packages and tell the user to name them appropriately (nx-personal-version.tar.gz, etc).
(In reply to comment #16) > Best/easiest/cleanest solution that I've seen mentioned somewhere is to fetch > restrict the packages and tell the user to name them appropriately > (nx-personal-version.tar.gz, etc). > That's a good possibility too. :) The only thing is that the user would need to maually download the file and rename it. I was hoping for a solution that wouldn't involve this. But, this is easier and we know the .rpms work. Thanks. :)
I'll get to this later on today.
(In reply to comment #18) > I'll get to this later on today. > 'today' stretched into 2+ months ;)
fixed by removal
