[gentoo-dev] Re: News Item: OpenAFS no longer needs kernel option DEBUG_RODATA
On Mon, 1 Aug 2016 14:08:57 +0300 Andrew Savchenko wrote: > Hi, > > On Wed, 20 Jul 2016 13:13:49 -0400 NP-Hardass wrote: > > This is the first draft of a news item describing a packaging change for > > OpenAFS so that we no longer require the DEBUG_RODATA be turned off. > > This is a second try with rewording of the first paragraph, since > it was suggested that it is a bit awkward. > > Title: OpenAFS no longer needs kernel option DEBUG_RODATA > Author: NP-Hardass > Author: Andrew Savchenko > Content-Type: text/plain > Posted: 2016-07-23 > Revision: 1 > News-Item-Format: 1.0 > Display-If-Installed: <=net-fs/openafs-kernel-1.6.18.2 > Display-If-Keyword: amd64 > Display-If-Keyword: ~amd64-linux > Display-If-Keyword: ~sparc > Display-If-Keyword: x86 > Display-If-Keyword: ~x86-linux > > As a result of bug #127084 [1], it was determined that OpenAFS's > kernel module required that the kernel's data structures be > read-write (CONFIG_DEBUG_RODATA=n). With recent OpenAFS versions > this limitation is no longer required. We tested the latest version > of OpenAFS with Linux kernels from 3.4 till 4.6, and determined that > OpenAFS kernel module works fine with CONFIG_DEBUG_RODATA=y. > > Starting with net-fs/openafs-kernel-1.6.18.2, this condition is no > longer forced in the ebuild. Considering the security implications > of having CONFIG_DEBUG_RODATA turned off, it is highly advised that > you adjust your kernel config accordingly. Please note that the > default setting for CONFIG_DEBUG_RODATA is "y" and unless you have > another reason for keeping it disabled, we highly recommend that > you re-enable CONFIG_DEBUG_RODATA. > > [1] https://bugs.gentoo.org/show_bug.cgi?id=127084 No comments for a week => submitted. Best regards, Andrew Savchenko pgpZO8cqeP0uo.pgp Description: PGP signature
[gentoo-dev] Re: News Item: OpenAFS no longer needs kernel option DEBUG_RODATA
Hi, On Wed, 20 Jul 2016 13:13:49 -0400 NP-Hardass wrote: > This is the first draft of a news item describing a packaging change for > OpenAFS so that we no longer require the DEBUG_RODATA be turned off. This is a second try with rewording of the first paragraph, since it was suggested that it is a bit awkward. Title: OpenAFS no longer needs kernel option DEBUG_RODATA Author: NP-Hardass Author: Andrew Savchenko Content-Type: text/plain Posted: 2016-07-23 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: <=net-fs/openafs-kernel-1.6.18.2 Display-If-Keyword: amd64 Display-If-Keyword: ~amd64-linux Display-If-Keyword: ~sparc Display-If-Keyword: x86 Display-If-Keyword: ~x86-linux As a result of bug #127084 [1], it was determined that OpenAFS's kernel module required that the kernel's data structures be read-write (CONFIG_DEBUG_RODATA=n). With recent OpenAFS versions this limitation is no longer required. We tested the latest version of OpenAFS with Linux kernels from 3.4 till 4.6, and determined that OpenAFS kernel module works fine with CONFIG_DEBUG_RODATA=y. Starting with net-fs/openafs-kernel-1.6.18.2, this condition is no longer forced in the ebuild. Considering the security implications of having CONFIG_DEBUG_RODATA turned off, it is highly advised that you adjust your kernel config accordingly. Please note that the default setting for CONFIG_DEBUG_RODATA is "y" and unless you have another reason for keeping it disabled, we highly recommend that you re-enable CONFIG_DEBUG_RODATA. [1] https://bugs.gentoo.org/show_bug.cgi?id=127084 Best regards, Andrew Savchenko pgptMnUs4dLsk.pgp Description: PGP signature
Re: [gentoo-dev] Re: News Item: OpenAFS no longer needs kernel option DEBUG_RODATA
On Sun, 24 Jul 2016 10:05:23 +0300 Andrew Savchenko wrote: > I agree with you, but REPLACING_VERSIONS has nothing to do with > such recovery. Yes, it does. Specifically, what we want is for developers to get into the habit of writing safe, clean code, even if they think they don't need to care about it in some particular situation because they can't think of how it would go wrong. It's the same as getting into the habit of sticking || die on things. > 1) It appeared only in EAPI 4, approved on 2011-01-17. Recovery > from hardware crashes forked well long before. Before this, you could use has_version in pkg_*, and it would tell you the *old* version of the package that was installed. The phase order changed a while ago, and broke this, so REPLACING_VERSIONS was the replacement. Again, the situation is complicated, there's a lot of messy history behind this, and if you don't know it all, just do what the spec says and stop wasting everyone's time by arguing. > 2) If you will look into the tree, in the absolute majority of cases > REPLACING_VERSIONS is being used to determine whether informational > messages should be shown to a user or not. Such messages usually > include some upgrade hints or howtos; and REPLACING_VERSIONS check > is required to avoid showing them to unaffected users. It has > absolutely nothing to do with the error recovery done by PM itself. Don't get into the habit of writing code that makes unnecessary assumptions that will come back and screw users over in unexpected situations. It's easy to do this the right way, so at this point I can only conclude that you're persisting in trying to do it wrong just to avoid admitting that you made a mistake from ignorance. It's OK to be wrong sometimes (and this is why code review exists), but it's not OK to continue to argue that you were right out of stubbornness. -- Ciaran McCreesh
Re: [gentoo-dev] Re: News Item: OpenAFS no longer needs kernel option DEBUG_RODATA
Hi, On Sun, 24 Jul 2016 03:00:40 + (UTC) Duncan wrote: > Andrew Savchenko posted on Sun, 24 Jul 2016 00:30:39 +0300 as excerpted: > > > Do we ever had such case like multiple versions of the same > > single-slotted package installed or recorded as installed in the real > > world? I'm not sure even in this, but I may assume that it may happen > > one day. > > > > Do we have any proof that PM can recover from such situation, > > where VDB is a mess and installed files can also be a mess? I'm not sure > > in this at all. > > > > Do we have any test suits for portage (as the most popular PM > > implementation) for such cases? I doubt this, I can find none. I'm not > > sure if such tests are implemented in other PM test suits too. > > Think of how a package is upgraded (by portage, I don't know enough about > the others to describe the process for them). The package is built, then > installed to a temporary location, then "qmerged" from the temporary > location to the live filesystem, replacing the previous version's files > and recording the new one in the installed-package database, then the old > version is unmerged and its record removed from the installed-package > database. > > What happens if there's a crash in either the qmerge or old-version > unmerge steps? > > Right, now there's parts of two versions in the installed-package > database, and who knows what files from each on the live filesystem. > > I'm not a portage dev so won't comment on the test suite angle, but > portage has been able to handle this with the user simply redoing the > upgrade (whether from binpkg or full rebuild) for many years now (singe > before I became a gentooer in 2004, I know as I had some faulty hardware > at the time and regularly crashed during build and installs, which was > likely before REPLACING_VERSIONS was a thing), and given the number of > installations out there and the stress of parallel-building some packages > while others are installing, the code to handle this is GOING to get > regularly tested. I agree with you, but REPLACING_VERSIONS has nothing to do with such recovery. 1) It appeared only in EAPI 4, approved on 2011-01-17. Recovery from hardware crashes forked well long before. 2) If you will look into the tree, in the absolute majority of cases REPLACING_VERSIONS is being used to determine whether informational messages should be shown to a user or not. Such messages usually include some upgrade hints or howtos; and REPLACING_VERSIONS check is required to avoid showing them to unaffected users. It has absolutely nothing to do with the error recovery done by PM itself. 3) I also had a broken hardware (faulty memory) for a few years and portage and other software recovered quite fine despite numerous segfaults. So I have the experience :) Best regards, Andrew Savchenko pgpUv30f2tv3O.pgp Description: PGP signature
[gentoo-dev] Re: News Item: OpenAFS no longer needs kernel option DEBUG_RODATA
Andreas K. Huettel posted on Sun, 24 Jul 2016 00:04:53 +0200 as excerpted: > 1) If a package only ever had one slot, it cannot ever have two versions > installed at the same time. That guarantee (of only ever one slot) can > be given for the portage tree (sic). Obviously it doesn't work for > overlays, > but there are many things we don't care about for overlays. [A] This is incorrect. It arguably /might/ be correct if systems were guaranteed never to crash in the qmerge or old-version unmerge phases, but... the package manager must be able to deal with and recover from such crashes, and portage has done so for well over a decade, at least. (When I became a gentooer in 2004 I had faulty hardware, and the system would regularly crash during merges, sometimes repeatedly. When I rebooted, all I had to do was restart the merge, and portage could pick up the pieces and deal with it, even back then.) > 2) If a package manager leaves two versions of a non-slotted package > "installed" somehow, that package manager is fundamentally broken and > its author should forever refrain from specifying anything. It's not our > job to work around Paludis failure modes. [B] Not if it's the hardware that's broken, not the PM. A good PM must be able to recover from the crash, and sort things out from it on a second, or third or tenth, attempt to actually get the upgrade done, this time /without/ crashing part way thru. And broken ebuilds that can't deal with the situation don't help matters at all. =:^( -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
[gentoo-dev] Re: News Item: OpenAFS no longer needs kernel option DEBUG_RODATA
Andrew Savchenko posted on Sun, 24 Jul 2016 00:30:39 +0300 as excerpted: > Do we ever had such case like multiple versions of the same > single-slotted package installed or recorded as installed in the real > world? I'm not sure even in this, but I may assume that it may happen > one day. > > Do we have any proof that PM can recover from such situation, > where VDB is a mess and installed files can also be a mess? I'm not sure > in this at all. > > Do we have any test suits for portage (as the most popular PM > implementation) for such cases? I doubt this, I can find none. I'm not > sure if such tests are implemented in other PM test suits too. Think of how a package is upgraded (by portage, I don't know enough about the others to describe the process for them). The package is built, then installed to a temporary location, then "qmerged" from the temporary location to the live filesystem, replacing the previous version's files and recording the new one in the installed-package database, then the old version is unmerged and its record removed from the installed-package database. What happens if there's a crash in either the qmerge or old-version unmerge steps? Right, now there's parts of two versions in the installed-package database, and who knows what files from each on the live filesystem. I'm not a portage dev so won't comment on the test suite angle, but portage has been able to handle this with the user simply redoing the upgrade (whether from binpkg or full rebuild) for many years now (singe before I became a gentooer in 2004, I know as I had some faulty hardware at the time and regularly crashed during build and installs, which was likely before REPLACING_VERSIONS was a thing), and given the number of installations out there and the stress of parallel-building some packages while others are installing, the code to handle this is GOING to get regularly tested. This needs to continue to work, thus the PMS rules, and ebuilds that are unprepared to deal with it aren't going to help. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
[gentoo-dev] Re: News Item: OpenAFS no longer needs kernel option DEBUG_RODATA
On 07/21/2016 01:12 AM, Michał Górny wrote:
> On Thu, 21 Jul 2016 00:22:36 +0300
> Andrew Savchenko wrote:
>
>> On Wed, 20 Jul 2016 15:12:01 -0400 Michael Orlitzky wrote:
>>> On 07/20/2016 01:13 PM, NP-Hardass wrote:
Display-If-Installed: <=net-fs/openafs-kernel-1.6.18.2
...
Starting with net-fs/openafs-kernel-1.6.18.2, this condition is no longer
forced in the ebuild.
>>>
>>> Might not that version bound might backfire if someone upgrades before
>>> reading the news? People who pull from git often don't necessarily get
>>> the news in a timely fashion.
>>>
>>> Would it be simpler to ewarn in the ebuilds (for e.g. a year) if
>>> DEBUG_RODATA=n?
>>
>> We already do this in openafs-kernel-1.6.18.2.ebuild:
>>
>> if use kernel_linux && [[ ${REPLACING_VERSIONS} < "1.6.18.2" ]]; then
>
> Few important QA notes:
>
> 1. < is lexicographical comparison, so e.g. 1.6.2.2 < 1.6.18.2 gives
> false,
>
> 2. REPLACING_VERSIONS can have more than one value,
>
> 3. Finally, '' < 1.6.18.2 gives true, so it is also printed for initial
> install.
>
If you want to do a package version comparison, you probably want to use
the function version_is_at_least() in versionator.eclass. The primary
version comparison function in that eclass was written to be a complete
implementation of the version comparison algorithm in PMS. Maybe
eventually we'll get a version comparison function in PMS so we won't
have to resort to the wonderfully complex bash functions in that eclass :).
--
Jonathan Callen
signature.asc
Description: OpenPGP digital signature
