In data venerdì 5 marzo 2021 18:16:18 CET, Glenn Strauss ha scritto: > On Fri, Mar 05, 2021 at 05:12:17PM +0100, Pino Toscano wrote: > > > Personally, I'd argue that switching the FAM implementation across the > > distribution _is_ a "transition", and as such it ought to have been > > requested (if not even started) two months ago. > > In July 2020, #966273 was filed: RFA: fam -- File Alteration Monitor > > I posted in October 2020 on that bug where FAM was abandoned. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966273#15 > Debian developers did not suggest "next steps" for over 3 months, > until the freeze occurred. > > The bug was not touched by a Debian Developer until 31 Jan 2021. This message was addressed only to bugs, one of them was assigned to "wnpp" and the other to libgamon0: this means that only the gamin maintainer (1 specific person, as there is no group maintenance) and who watches the bugs of wnpp and src:gamin actually read it. Becuase of this, its audience was limited, and neither the general list for Debian development (debian-devel) nor the release team (release-team) were notified/aware of it by default. I can understand your frustation, but that is not a reason to rush things just because of this. All the deadline for Debian releases have been more or less streamlined/standardized for at least the past 2 stable releases already, so every step is well known in advance. Because of this, for example, we were not able to provide Plasma 5.12 in Bullseye. > The solution is to remove FAM. And nobody, really, *nobody* ever said the opposite, so please stop repeating that it is not wanted. > Back on topic: > > If you take a moment to look in the kcoreaddons code, you can see that > kcoreaddons has multiple mechanisms for filesystem notification. > If FAM interfaces fail for any reason, kcoreaddons switches to an > alternative mechanism. > https://invent.kde.org/frameworks/kcoreaddons/-/blob/master/src/lib/io/kdirwatch.cpp#L1611 > > Therefore, your FUD is unsubstantiated. Changing kcoreaddons to use > gamin, or to not use FAM or gamin, are both reasonable options. > As I posted in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981515#49 > gamin can be configured to poll NFS locations and so is a reasonable > substitution for FAM, not limited to inotify() as Sune suggested in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981515#39 Sure, I well know that KDirWatch in kcoreaddons builds fine with either libfam or gamin as "FAM", I remember people doing this many years ago in other distributions. However, what I said is something completely different, let me summarize it in short points for easier understanding: - I am fine switching from libfam to gamin in the future - I am fine dropping libfam from Debian in the future - I want first libgamin to stop providing libfam - switching from libfam from gamin *is* switching FAM implementation, and thus which code is used for "FAM", and possibily different bugs; hence, this is *too late* to properly test is in Bullseye There is no FUD in what I said. > It is true that this relatively safe change is being requested during > the soft freeze and so should be scrutinized. However, that does not > make the requested change any more or less dangerous. It does mean > less time to test by people who, in your own words, might not be using > this feature: > > and these FAM/gamin bits do not get much of use these days So if, "less time to test by people who [...] might not be using this feature", this switch is even more dangerous. Thanks from proving my point. > I posit that the code in upstream kcoreaddons is already better tested > than would be Debian "testing" (existence in tree?) of an additional > month or two or three of the Debian kcoreaddons package configured to > use gamin (or to use neither FAM nor gamin). This "additional month or two or three" we are talking about is called "Debian freeze". Dependency changes like this are very much *not* the kind of changes we want to introduce during a freeze. -- Pino Toscano
Attachment:
signature.asc
Description: This is a digitally signed message part.