Bug#776413: Policy violation: ed priority "optional", should be "important"
Paul Hardy writes ("Bug#776413: Policy violation: ed priority "optional",
should be "important""):
> I know that the package priority is up to the FTP Masters and not up
> to any of us. I just mention the above as input for the ed maintainer
> to discuss with the FTP Masters if so desired.
I thought the bug that ed was not in the default install had been
fixed. I agree that it ought to be in all but the most minimal
installations.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#776413: Policy violation: ed priority "optional", should be "important"
I considered using "ed" in a script to massage an upstream package into shape during installation this past week, but decided not to because ed is not part of the default Debian installation. I think it is worth considering why ed is part of the POSIX standard to this day in determining whether or not it should have priority "important" and be included in the base installation. The very first sentence of the "DESCRIPTION" portion of the BSD 4.2 man page (1980s vintage) for ed says: "_Ed_ is the standard text editor." Historically, ed was the only text editor available on a bare-bones Unix system booting from a minimal kernel before a customized kernel had been configured and built, with video drivers, etc., to support video monitors. Most processors today are not connected to video monitors; most processors are part of embedded systems. When bringing up such a system initially, you typically just have a power supply, the processor chip, some flash memory that contains a minimal bootloader, a serial console port on the processor's UART pins, and maybe a JTAG port. This bug report has mentioned vi(m) and sed as possible replacements. Neither are proper interactive single-line editors designed to work over a serial line, and GNU sed is more powerful than other sed implementations, and vi(m) is not suitable for operation within a shell script. Embedded systems are not going to be reporting their usage for popcon statistics either, so a poor popcon showing can be misleading. The Debian source package is about 1 Mbyte, almost half of which is testsuite data, but the upstream tarball is less than 70 kilobytes. Is Debian so constrained for space on its ISO images that it is not possible to shoehorn in a copy of ed in the base installation? I know that the package priority is up to the FTP Masters and not up to any of us. I just mention the above as input for the ed maintainer to discuss with the FTP Masters if so desired. Thank you, Paul Hardy
Bug#776413: Policy violation: ed priority "optional", should be "important"
Martin Zobel-Helas : > it has been recently brought to my attention, that Debian policy > considers packages that are part of POSIX standard should be part of > every Debian installation. ed is still a part of POSIX, that is The Open Group Base Specifications Issue 7 IEEE Std 1003.1-2008, 2016 Edition, which is available at Open Group website [POSIX]. More specific one can easily find a page on ed [ed]. I'm not sure about the exact interpretation of the passage from Debian Policy, that is "Important programs, including those which one would expect to find on any Unix-like system." [policy], but I guess that if ed is a part of POSIX then anyone who is familiar with the standard expect to find it in any Unix-like system. The problem here is what "Unix-like" means. In case it means full accordance with POSIX, then ed should be included in the important section. But if "Unix-like" means that a given system is made more or less in accordance with POSIX, then obviously it is questionable that ed should be classified as important. [POSIX] http://pubs.opengroup.org/onlinepubs/9699919799/ [ed] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ed.html [policy] https://www.debian.org/doc/debian-policy/#priorities With regards, Lev Lamberov
Bug#776413: Policy violation: ed priority "optional", should be "important"
Hi Andreas, On Tue Jan 09, 2018 at 04:51:23 +0100, Andreas Henriksson wrote: > Control: tags -1 + wontfix > Please also note that if you seriously argue that this is a policy > violation the severity should be 'serious'. it has been recently brought to my attention, that Debian policy considers packages that are part of POSIX standard should be part of every Debian installation. I am currently traveling and don't have proper and reliable internet connection. But that should be verified and if the Debian policy mentions the above, ed should in fact go back to important. Best regards, Martin -- Martin Zobel-Helas Debian System Administrator Debian & GNU/Linux Developer Debian Listmaster http://about.me/zobel Debian Webmaster GPG Fingerprint: 6B18 5642 8E41 EC89 3D5D BDBB 53B1 AC6D B11B 627B
Bug#776413: Policy violation: ed priority "optional", should be "important"
Control: tags -1 + wontfix Hello, I'm not the maintainer but given the recent RFH (#886643) I'm taking the liberty of wontfix tagging this bug report and will outline my reasoning below. First of all I personally disagree with what has been stated in this bug report and think the current priority is correct. For the reason stated in #416585 I also think the current situation aligns well with what policy says. (But please also note that AFAIR there has been discussions on potentially improving the policy wording.) I don't find the reasoning that ed is useful as a last resort is so convincing given that vi(m-tiny) should be able to fill that role just fine (or sed as you mentioned). Also there seems to be no reason given to why installing it when needed isn't true. This bug report may also be considered misdirected, given it's not even up to the package maintainer to control the priority as that is done in the overrides file controlled by the ftp-masters (see http://bugs.debian.org/ftp.debian.org). Please also note that if you seriously argue that this is a policy violation the severity should be 'serious'. Regards, Andreas Henriksson
Bug#776413: Policy violation: ed priority "optional", should be "important"
Package: ed Version: any The priority of the ed package has been changed to "optional". According to the changelog this is apparently for no reason other than a response to bug #416585, the content of which is simply one person's suggestion which he makes without providing any justification beyond his personal whim. The Debian policy manual http://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities says: "If the expectation is that an experienced Unix person who found it missing would say "What on earth is going on, where is foo?", it must be an important package." Surely it is beyond question that this applies to ed. Anyone needing to edit a file via a simple line-oriented interface on a Unix-like system will automatically reach for ed and will be most disconcerted to find it missing. And certainly ed used to have priority "important" as this suggests it should. The assertion in bug #416585 that "anyone who wants it can easily install it" is not true. The principal value of ed is that it is an editor which works when nothing else does. If the system is broken, or incompletely installed, or only accessible via the most primitive of interfaces, or in other situations of a like kind, which are the sort of situations in which ed or an equivalent is likely to be the only editor that is usable at all, it is also highly likely that installing ed (or anything else for that matter) will be impossible. And the lack of a functional editor makes it many times harder to fix whatever problem has given rise to the need for it. I have recently been caught this way a couple of times myself. In one case I was able to copy /bin/ed from another system onto a USB stick and use that. In another I had to use yucky workarounds like sed -i -e 'editing commands' 'filename'. Another virtue of ed is that it is possible to use it to patch binaries without the risk that arises with less primitive editors of some automatic formatting function messing the whole thing up. For instance if a hard-coded pathname is causing problems then ed is capable of changing it to something else of the same or shorter length with no collateral damage. The kind of situation in which such a problem is likely to arise is also the kind of situation in which editing the source and recompiling is likely to be impossible. In short, not only is it a policy violation for ed to have priority "optional", it also means that an important repair and rescue tool is likely to be unavailable when it is most needed. Therefore I strongly suggest that the priority for ed be reset to "important". -- Pigeon Be kind to pigeons- -Pigeon's Nest: http://pigeonsnest.co.uk/ GPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F signature.asc Description: Digital signature
