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
Never repackage a release with same version number #5126
Comments
Thanks for the feedback! As release manager I really try to avoid doing this as I know it's bad and causes troubles. But IMO it's still better than doing another point release just to fix a non critical bug in the release itself (such as the missing manifest file). So I will do my best to not have to re-package like we did recently, but I cannot promise that I will follow the best practise. Thanks a lot for your work packaging Piwik for FreeBSD! |
Hello, my name is John Marino. I strongly urge the piwik project to follow the best practice under every circumstances. The act of creating a new tarball with the same name is called "rerolling". No package system can tolerate rerolling: not Debian, not Fedora, not pkgsrc, and not FreeBSD Ports collection. If the hash digest doesn't match, the port is rejected as a man-in-the-middle attack. How can a user be sure the distribution file doesn't contain malware after the checksum fails? From my point of view, if piwik continues this frankly amateur approach to releases, there are only two possible outcomes:
I would like to iterate that this is not a BSD thing - Linux package system abhor this practice too. It's a really, really bad thing. I urge you to release as many point releases as necessary and never, ever produce a new tarball with a previously used filename. Sincerely and regards, |
btw, I think "point release" is the wrong term. It's not a new release, it's just a revision on the packaging. I suggestion something like piwik-2.2.2.tar.gz => piwik-2.2.2a.tar.gz => piwik-2.2.2b.tar.gz so the naming makes it clear it's the name release, but the contents of the tarball have changed. Pick whatever scheme you want; the only requirement is that each name is unique. |
Hi John, thanks for your points... To prevent most errors of repackaging, please consider waiting 48 hours before issuing the FreeBSD port. This should prevent the problem in most cases... Cheers |
In 23c6586: Display the SHA1 checksum in the email to Microsoft Web App team, after building a stable release. Refs #5126 I apologise in advance for again re-packaging 2.2.2.. We agree with you that is not acceptable policy from us. Cheers |
…er building a stable release. Refs matomo-org#5126 I apologise in advance for again re-packaging 2.2.2.. We agree with you that is not acceptable policy from us. So we are now committed to you guys the FreeBSD community, and to Microsoft, to never re-package a release from now on. Cheers
Hi, I'm the maintainer of the Piwik port (package) in FreeBSD - see http://www.freshports.org/www/piwik/
FreeBSD ports require the files from a release to be unchanged - same size and MD5 sum. If not, the port will not install or update.
It seems the Piwik team has a practice of repackaging without changing version number for minor changes. This has happened many times - recently with the 2.2.1 release (where vendor/sebastian was removed).
I urge you to stop with this practice. AFAICT it's not good for security and very bad for FreeBSD ports and other package management solutions that build from source.
The text was updated successfully, but these errors were encountered: