On Tue, Jun 20, 2017 at 02:48:02PM +0200, Michael Biebl wrote: > On Wed, 25 Jan 2017 14:42:36 +0100 [email protected] wrote: > > Package: bit-babbler > > Version: 0.6 > > Severity: normal > > User: [email protected] > > Usertags: udevadm > > > > Hi, > > > > since Jessie, the udevadm binary is available as /bin/udevadm. > > To not break existing scripts, which use the old /sbin/udevadm path, > > the udev package currently ships a compat symlink which we would like > > to drop eventually (in buster or buster+1). > > > > According to codesearch [1] your package bit-babbler does hard-code the > > udevadm path as /sbin/udevadm. > > > > Please change that to /bin/udevadm. > > With stretch being released and buster open for development, it would be > a great opportunity to get this fixed now. So please consider adding > this change in your next upload.
I am in the process of wrapping things up for making a new upstream release of this shortly. > If you are worried about backports: /bin/udevadm is already available in > Debian jessie (oldstable) or Ubuntu trusty (14.04LTS). So it's safe to > use the /bin/udevadm path. Unless I'm missing something it will break for Wheezy though, which is still an LTS maintained release for about another year? And as an upstream part of the package, we do expect to be portable to other distros too - so I'd guess there's also things like RHEL releases where the old path might still be in use for quite some time to come? The code this is in is an example hook called by libvirt/QEMU, so it's probably not entirely safe to make (m)any assumptions about what may be in PATH either (or at least not that /sbin may always be in it where that is still needed). Which I think means that if you guys want to drop the compat link to the old path, then this script either needs to search for where it really is on a given system - or we end up with an upstream faq to answer for a few years, telling people they'll need to hand hack the path themselves ... ... and then those people will say "why don't you just search for it if you know that it moved?" ... Which seems like a reasonable question to not make them ask :) Users shouldn't need to be on the pointy end of fallout from letting this change propagate down the chain of who needs to deal with it. Cheers, Ron
