Control: affects -1 eject Hi,
On Mon, May 04, 2020 at 12:08:10PM +0200, Chris Hofstaedtler wrote: > Hi everyone, > > (Adding CC: mpitt@, as the dmcrypt-get-device author.) > > * atzlinux 肖盛文 <atzli...@sina.com> [200504 05:16]: > > Hi Chris, > > > > 在 2020/5/4 上午6:09, Chris Hofstaedtler 写道: > > > Hi xiao sheng wen, > > > > > > I've noticed you've recently taken over maintenance of the eject > > > package, after it was unmaintained for years. > > > > > > Probably unbeknownst to you, plans were made to replace the eject > > > (and eject-udeb) packages with code from util-linux. > > > > I didn't know this plan before,I can't get this info from the RFA > > bugreport of eject(#924444). > > Yeah. Sorry about that. FWIW this bug report was originally assigned to the eject package, but someone reassigned it over to util-linux when they thought it was up to util-linux to implement the solution. Unfortunately there was no "affects" set up which would have made it show up on both sides. Thus my (too late) attempt at doing so at the top of this message now to make the bug report show up in the bug tracker for both packages. (I guess at the time noone thought it would take this long to get this issue fixed and that anyone else would need to be brought into the loop before we had this issue squashed.) > > > > I understand that it must be somewhat soul-crushing when this > > > happens, so I wanted to loop you in. > > > > Never mind! Thanks for loop me in. > > > > I'm just learning packaging .I hope contribute to Debian,let Debian > > become more better. > > > > > Do you think it's alright if we move forward with replacing the old, > > > dead-upstream eject with the code from util-linux? > > > > The eject upstream git repo is [1],from the log ,I know the lasted > > commit[2] is on Aug 21 21:42:30 2019. > > > > Is this a dead-upstream? > > Doesn't look dead now, no, but it certainly was for a long time. > See below for a bit more. No matter if its dead or not, other (well known) distributions use the util-linux implementation. The questions I think we need to ask ourselves are: Whats the purpose of deviating from other distros? Why can't we have a single upstream source and work together? What's the value-add in using different implementations? The value in everyone using the same implementation is quite easy to answer: Scripts and other users of the program automatically is (more) portable between different distributions. > > > > My plan would be to take over the eject, eject-udeb packages sometime > > > next week (obviously going through NEW, so maybe a bit later). > > > > I'd read the bug #737658,from this bugreport,I learned more info about > > udeb,d-i,etc. :-) > > > > IMHO,I had a little worry about commands: volname and > > dmcrypt-get-device(suid). > > > > volname is still used by dkopp[3]. > > Right. So: > > 1) who is using dmcrypt-get-device, and why does it exist in the > first place? Martin, can you shed some light on this? > I can't find anything using it (via codesearch.debian.net); I'm > guessing this was used for/by udev a long time ago, but that can use > any of the libraries directly? I don't know the original user for this either, but AIUI it's definitely deprecated now and should be safe to get rid of. > > 2) volname apparently uses knowledge about ISO9660 directly, and > personally I'd rather see users use blkid instead, like so: > /usr/sbin/blkid -s LABEL ./debian-10.3.0-amd64-netinst.iso > ./debian-10.3.0-amd64-netinst.iso: LABEL="Debian 10.3.0 amd64 n" > (This works for anything that's got a label, not just ISO9660 > files/devices.) > I can try a minimal patch to dkopp. (Also dkopp doesn't depend on > eject -- how did you find this?) ... and as soon as someone brings up blkid I can't help but mention that lsblk is the modern replacement (although not available in udeb). > > > After the replace plan finished,Are these two commands will disappear in > > Debian 11 ? > > > > If has one shell scripts used these two commands in Debian 10,when the > > OS update to Debian 11, > > > > Do the shell scripts need to modify?How to modify? > > blkid can be used to replace volname; not sure if a replacement for > crypt-dev-device is actually needed? > > I'd really like to see us move away from Debian-specific tools, > especially if they're undocumented and/or have security impact. > While the tools shipped in util-linux are sometimes not great, I > think util-linux's upstream is in a way better situation, with a lot > more willing helping hands (and eyes, too). Agreed. And more eyes/help is welcome. Atleast the upstream util-linux project is quite nice to get involved with if you're interested. > > Best, > Chris > Regards, Andreas Henriksson
