Bug#966273: Bug#510368: libgamin0: libfam shlib dependency wrongly set to libfam0
Hi! On Mon, 2021-02-01 at 00:06:45 +0100, Chris Hofstaedtler wrote: > Control: reassign -1 ftp.debian.org > Control: retitle -1 RM: fam -- RoQA; replaced by gamin; unmaintained; > upstream dead > Control: tags -1 + moreinfo > please remove fam. Upstream is long gone, and gamin is a maintained > drop in alternative. The previous Debian maintainer of fam has > orphaned it. Hmm, gamin might have been maintained (at least relative to fam) at the time it was introduced, but it does not look that way anymore, neither upstream nor Debian TBH: See f.ex.: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/219 https://bugzilla.gnome.org/show_bug.cgi?id=482704 https://gitlab.gnome.org/Archive/gamin (archived) https://people.gnome.org/~veillard/gamin/sources/ (last release 2008) https://mail.gnome.org/archives/gamin-list/ (last mail 2016) I think gamin should be removed from Debian too. Thanks, Guillem
Bug#510368: libgamin0: libfam shlib dependency wrongly set to libfam0
* Helmut Grohne : > On Fri, Aug 07, 2020 at 12:28:17PM +0200, Stefan Bühler wrote: > > I think fixing libgamin0.shlibs and dropping fam from the archives is > > the smoothest path to fixing this mess. > > Well, yeah. Removing fam removes the whole mess of compatibility. #966273 has become RM: fam, so please fix the gamin side of this. Many thanks, Chris
Bug#966273: Bug#510368: libgamin0: libfam shlib dependency wrongly set to libfam0
Control: reassign -1 ftp.debian.org Control: retitle -1 RM: fam -- RoQA; replaced by gamin; unmaintained; upstream dead Control: tags -1 + moreinfo Dear ftpmasters, please remove fam. Upstream is long gone, and gamin is a maintained drop in alternative. The previous Debian maintainer of fam has orphaned it. +moreinfo, there are some r-deps left. Chris
Bug#510368: libgamin0: libfam shlib dependency wrongly set to libfam0
cross-posting to: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966273 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510368 stbuehler wrote: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966273 > Is there any reason to keep FAM around any longer in your opinion, > given upstream is dead and there is gamin? > > Or, in other words, why didn't you file a package removal request? > > Imho providing a package that runs a (even if just local) service as > root doesn't combine well with a dead upstream with regards to > security. > > I see the following reverse dependencies in aptitude: > > fam: (recommends) gnubiff > > libfam0: (depends) > courier-base > courier-imap > doodled > gnubiff > libkf5coreaddons5 > lighttpd > omake > sqwebmail > > Is any of these known to actually need fam instead of gamin? Negative. I just scanned the source code and *none* require FAM. gamin limitations according to https://people.gnome.org/~veillard/gamin/differences.html "The functions FAMSuspendMonitor(), FAMResumeMonitor() and FAMMonitorCollection() are not implemented. They all raise problem of accumulating unbounded state on the server side and better handled at the client level if needed." A simple egrep "FAMMonitorCollection|FAMSuspendMonitor|FAMResumeMonitor" through source code finds that none of the above packages use those APIs except omake. omake provides its own implementation of the FAM APIs, and on Linux, uses its own implementation employing inotify(). omake provides a kqueue implementation for *BSD, and a Win32 implementation for Windows. On other platforms, it uses FAM. To repeat, on Linux, omake uses its own implementation of FAM APIs employing inotify(). See omake source code lib/configure/fam.install None of the other packages reference the APIs in FAM missing in gamin. doodle and omake reference FamErrlist[FAMErrno], but if FAM is removed, building and depending on gamin has consistent behavior. ==> Therefore, it should be possible to remove FAM from Bullseye, and to change package dependencies from libfam-dev to libgamin-dev in Bullseye. ==> What are the next steps to remove FAM from Bullseye? Can the following be turned into a package removal request? RFA: fam -- File Alteration Monitor https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966273 Cheers, Glenn https://tracker.debian.org/pkg/courier http://www.courier-mta.org/repo.html https://github.com/svarshavchik/courier https://github.com/svarshavchik/courier-libs Debian packages: courier-base courier-imap sqwebmail https://tracker.debian.org/pkg/doodle http://http.us.debian.org/debian/pool/main/d/doodle/ https://tracker.debian.org/pkg/gnubiff http://gnubiff.sourceforge.net/ https://tracker.debian.org/pkg/kcoreaddons https://invent.kde.org/frameworks/kcoreaddons https://tracker.debian.org/pkg/lighttpd https://salsa.debian.org/debian/lighttpd https://tracker.debian.org/pkg/omake https://salsa.debian.org/ocaml-team/omake
Bug#510368: libgamin0: libfam shlib dependency wrongly set to libfam0
Control: severity -1 serious On Fri, Aug 07, 2020 at 12:28:17PM +0200, Stefan Bühler wrote: > This is an actual problem, as libfam0 doesn't provide the FAMNoExists > symbol, but programs building against libgamin-dev might detect the > symbol as available and use it. I concur. > So libfam0 can't properly provide "libfam.so*" from libgamin0, and > shouldn't be allowed to by libgamin0.shlibs. You mix two separate problems here: * libfam0 has functionality that libgamin0 doesn't. This is #438330. * libgamin0 has functionality that libfam0 doesn't. This is #510368. To fix the former, libgamin0 should stop providing libfam0. The relevant bug is tagged wontfix and as far as I can see, it no longer has practical consequences. It also is kinda intentional. Dropping the provides would against the intention of gamin. However this bug has practical consequences now. If you build lighttpd against gamin and then use it with fam, it breaks. I argue that therefore, the shlibs part and providing libfam-dev is wrong. How bad is this? If your gamin/fam consumer package wants to support both fam and gamin, it can simply build against fam and work with gamin. If you want to integrate with gamin, you build with gamin. So it doesn't actually add value. The trade-off seems clear here. So I think the part where the shlibs file claims libfam0 to suffice is a release critical bug. Reasonably using libgamin-dev can result in a binary that fails to run. In effect, this is similar to a missing dependency and missing dependencies are release critical. A possible solution would be adding a symbol file such that using a gamin-specific symbol results in a proper libgamin0 dependency while using any other symbol would continue to result in a libfam0 dependency. I'm not sure whether the effort is warranted given that fam is dead. > I think fixing libgamin0.shlibs and dropping fam from the archives is > the smoothest path to fixing this mess. Well, yeah. Removing fam removes the whole mess of compatibility. Helmut
Bug#510368: libgamin0: libfam shlib dependency wrongly set to libfam0
Hi, On Thu, 1 Jan 2009 10:46:05 +0100 =?iso-8859-1?Q?Lo=EFc?= Minier wrote: > On Wed, Dec 31, 2008, Andres Mejia wrote: > > The libfam shlib entry in libgamin0 is wrongly set to libfam0. Since > > libgamin > > is provided as a replacement for libfam, the entry should be set to > > libgamin0. This is a problem for packages that build depend on libgamin-dev > > since their dependency on libfam gets set to libfam0 instead of libgamin0. > > > > A fix for this would be to simply set the entry as "libfam 0 libgamin0". > > Better yet, just delete the libgamin0.shlibs file from the debian directory > > and let the shlibs file be automatically generated. > > I think you misunderstood the current shlibs; the point is to allow > building against the FAM API and ABI and depend on libfam0 (provided by > libgamin0) if programs are linked to libfam. This means you can > build-dep on fam or on gamin if you use the FAM API and this will > result on a dep on the FAM ABI and allow users to install either FAM or > Gamin as an implementation of the FAM ABI. You can also use the Gamin > API and link to libgamin which will result in a dep on the Gamin ABI. > > What problem are you trying to solve? This is an actual problem, as libfam0 doesn't provide the FAMNoExists symbol, but programs building against libgamin-dev might detect the symbol as available and use it. So libfam0 can't properly provide "libfam.so*" from libgamin0, and shouldn't be allowed to by libgamin0.shlibs. (As the gamin homepage says "The functions FAMSuspendMonitor(), FAMResumeMonitor() and FAMMonitorCollection() are not implemented." I think libgamin0 shouldn't have ever provided libfam0 either - it's basically broken in both directions.) I think fixing libgamin0.shlibs and dropping fam from the archives is the smoothest path to fixing this mess. Also see: - https://salsa.debian.org/debian/lighttpd/-/merge_requests/18 - https://bugs.launchpad.net/bugs/1453463 [lighttpd] "undefined symbol: FAMNoExists" - https://bugs.debian.org/966273 "RFA: fam -- File Alteration Monitor" (also: FAM upstream has been dead for some time) - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=438330 "Symbol `FamErrlist' has different size in shared object, consider re-linking" (this was just an annoying warning, not a real issue) - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=438552 "libgamin0: is Conflicts: libfam0 still necessary/valid?" (2007: perhaps libfam0 wasn't "provided" at the time?) cheers, Stefan
Bug#510368: libgamin0: libfam shlib dependency wrongly set to libfam0
On Wed, Dec 31, 2008, Andres Mejia wrote: > The libfam shlib entry in libgamin0 is wrongly set to libfam0. Since libgamin > is provided as a replacement for libfam, the entry should be set to > libgamin0. This is a problem for packages that build depend on libgamin-dev > since their dependency on libfam gets set to libfam0 instead of libgamin0. > > A fix for this would be to simply set the entry as "libfam 0 libgamin0". > Better yet, just delete the libgamin0.shlibs file from the debian directory > and let the shlibs file be automatically generated. I think you misunderstood the current shlibs; the point is to allow building against the FAM API and ABI and depend on libfam0 (provided by libgamin0) if programs are linked to libfam. This means you can build-dep on fam or on gamin if you use the FAM API and this will result on a dep on the FAM ABI and allow users to install either FAM or Gamin as an implementation of the FAM ABI. You can also use the Gamin API and link to libgamin which will result in a dep on the Gamin ABI. What problem are you trying to solve? -- Loïc Minier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#510368: libgamin0: libfam shlib dependency wrongly set to libfam0
Package: libgamin0 Version: 0.1.9-2 Severity: important Tags: patch The libfam shlib entry in libgamin0 is wrongly set to libfam0. Since libgamin is provided as a replacement for libfam, the entry should be set to libgamin0. This is a problem for packages that build depend on libgamin-dev since their dependency on libfam gets set to libfam0 instead of libgamin0. A fix for this would be to simply set the entry as "libfam 0 libgamin0". Better yet, just delete the libgamin0.shlibs file from the debian directory and let the shlibs file be automatically generated. -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libgamin0 depends on: ii gamin 0.1.9-2File and directory monitoring syst ii libc6 2.7-16 GNU C Library: Shared libraries libgamin0 recommends no packages. libgamin0 suggests no packages. -- no debconf information -- Regards, Andres signature.asc Description: This is a digitally signed message part.
