| Summary: | Should not drastically alter use flags on minor version change in www-servers/nginx | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Adam Walker <adam.walker> |
| Component: | New packages | Assignee: | Gentoo Linux bug wranglers <bug-wranglers> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | notordoktor |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Adam Walker
2010-03-07 23:53:04 UTC
1/ Yeah, don't upgrade things blindly :P There's --pretend/--changelog for a reason. 2/ Broken webserver != broken system 3/ Not really sure what you mean by grandfathered in, but ebuilds may only use such USE flags that they state in IUSE and not any else, let alone based on previous value of no longer existing flags. 1) Updating from 0.8.33 to 0.8.34 should not require this. It's a bugfix release. But yeah, I always use -p because portage has a habit of breaking things. Like with the update of nginx. 2) You know what I meant. 3) If you rename the flag, keep the old in IUSE instead of replacing it both unannounced and undocumented. (In reply to comment #2) > 1) Updating from 0.8.33 to 0.8.34 should not require this. It's a bugfix > release. But yeah, I always use -p because portage has a habit of breaking > things. Like with the update of nginx. How's portage breaking things? Flags change all the time, waiting for a major release to do use flags changes will get no work done ever. Plus, you are running ~arch where frequent changes are expected. > 3) If you rename the flag, keep the old in IUSE instead of replacing it both > unannounced and undocumented. That would defeat the entire point of the changes done in the ebuild, to make it cleaner and more flexible via USE_EXPAND. Totally a non-option. Plus, it's perfectly documented in - Changelog - /usr/portage/profiles/desc/nginx_modules_{mail,http}.desc) I really shouldn't have blamed portage, but rather, package maintainers. As an example, you can't update sendmail without it overwriting your files in /etc/mail, before you even get to the dispatch-conf stage. USE flags do change all the time, but not so drastically on a bugfix version bump. Can you show me which line in the Changelog says that you *MUST* change your use flags if you wish for it to behave like the older version? Figuring out exactly what I needed to change was time wasted that could have been better spent on running security updates on my other machines. I don't get what do you mean by this "bugfix" thing. Forget about upstream, you get arch and ~arch with Gentoo, not "bugfix". On another note, what are you proposing here? Make a totally messy ebuild that uses both old and new flags (which will make users file *valid* bugs about such horrible behaviour) or revert the changes and cause more havoc on users who have already migrated? Go mail -dev ML with a suggestion to add a news item when this hits stable and don't waste your time on bugzilla with something that's by no means a bug. (In reply to comment #0) > Between 0.8.33 and 0.8.34-r1, the use flags and default options have been > changed significantly enough that an update would result in a broken system. > Both the old flags should have been grandfathered in, and the new defaults > reflect the previous defaults. Failing that, the massive change should have > waited until a major version change (for nginx, 0.9 would be the major version > change). As far as I can tell those changes to ebuild were made for a reason, namely: 07 Mar 2010; Benedikt Böhm <hollow@gentoo.org> +nginx-0.8.34-r1.ebuild, files/nginx.conf-r4, +files/passenger-CFLAGS.patch, metadata.xml: rewrite ebuild for USE_EXPAND goodies. fixes bug 286772, bug 301513, bug 303205 and bug 305691 Moreover -r1 signifies change in ebuild not in source of the package. I am sorry but I cannot qualify your report as bug. Closing. Best regards, Kacper Kowalik |
