Bug#994275: Reverting breaking changes in debianutils
On Tue, Oct 26, 2021 at 09:53:55PM +0200, Thorsten Glaser wrote: > “It only exists if it’s in Debian.” > > SCNR. But this is relevant, here. > > [ overly harsh words deleted ] That's right, so we print a deprecation warning at the beginning of the development cycle to raise awareness of the situation and this leads to the interested parties packaging the whiches they want to see in Debian over the subsequent ~2-year period. This didn't work for tempfile because everyone still using tempfile seems to redirect stderr to /dev/null and never saw the warning. Ironically, it seems it hasn't yet worked for the original catalyst, but it has worked for GNU which, modulo the problem of the NEW queue. As a side effect, it seems to have shined a spotlight on some broken build systems.
Bug#994275: Reverting breaking changes in debianutils
On Tue, Oct 26, 2021 at 12:46:43PM +0200, tito wrote: > It is possible to create a single command package if somebody > will maintain it ( e.g busybox-which) like it was done for busybox-syslogd. > tempfile is missing tough. If someone wants to do that, I suppose they can. On Tue, Oct 26, 2021 at 01:53:29PM +0100, Wookey wrote: > I didn't understand why you wanted to make this change in the first I think I tried to explain this to you on another mailing list. There are people who are dissatisfied with the status quo with respect to which(1). I, as a user, don't care at all about which(1). I, as debianutils upstream, do not want to spend any effort maintaining a utility which is superfluous given the existence of alternatives which are preferred by people who care about this stuff. Now, as a debianutils maintainer in Debian, I could choose between various different approaches, taking into account different objectives to accommodate different stakeholder groups. It is important to acknowledge that it is impossible to please all groups here. One approach is to embrace the status quo. which(1) is perfectly fine as it is, and anyone who wants `which -s` or `which --read-functions` is a fool, an idiot, or worse. Those people don't matter and they should shut up. I believe that this is roughly equivalent to the original demand at the start of this bug report. I'll call this the ultraconservative approach. It is predicated on bad values and produces a bad outcome. Another is to cautiously embrace change at a glacial pace. This signals to people who want something else that they are largely unimportant, but as a gesture of good will, they can be accommodated eventually, maybe in 2 years, maybe in 10. It might seem reasonable in a subculture which is stratified and resistant to change, with stability (even the stability of _unstable_) paramount. I'll call this the conservative approach. It is predicated on bad values and produces a bad outcome. Another is to build a runway for people to get what they want and remove myself from the equation. This is what I have attempted to do. Now, provided anyone elects to maintain them and the FTP team allows them in, users will be able to install and use GNU which, *BSD which, busybox which, rewrite-it-in-rust which, or whatever should float someone's boat. I can think all of this is pointless, and it doesn't matter, because I am not impeding anyone else in their pursuit of which(1) apotheosis. > place, and I don't understand why you didn't just revert the message > when it became clear that it was a problem, and I don't understand why > you are still trying to justify your somewhat bloody-minded approach > to this (should-have-been) minor issue, even after the tech comittee > have agreed that it was not a good approach. You seem angry that I haven't expended effort to work around a bug in some other software. You also seem angry that I am not following a process that I am explicitly calling a bad process. Other people have said that "this is the way Debian does things," but I have been doing this for 25 years and I recall Debian doing things many different ways. I'll save my commentary on the quality of the TC's decision until after they have made it. > Please, just remove the deprecation message, until GNU which is in > unstable (like you should have done a couple of months ago, when first > asked), then work out how the transition should go such that no-one > using which will actually notice or care. Then you can throw away the > hated binary :-) and we can all be happy. When will GNU which be in unstable?
Bug#994275: Reverting breaking changes in debianutils
On Sat, Oct 16, 2021 at 05:56:17PM +0200, Thorsten Glaser wrote: > No. You’re conflating “which ”, which indeed is mostly redundant > with “command -v”, with “which -a ”, which is NOT otherwise > available, and a very useful thing to have, and one which (heh, pun > not intended) I pretty much expect to exist on a system. I can think of no reason why anyone would need to run `which -a` from a maintainer script. For interactive use, csh (and tcsh) never had -a for `which`. The reason that zsh has `which -a` is because it shares code with `whence -a`, which was taken from ksh in the '80s. Of course there's no telling whether it would have evolved later on if it had been originally csh-compatible. > I know that feeling… some package maintainers don’t seem to care about > warnings. But as something in an Essential package I fear it’s up to > you to ping them, time and time again, until they don’t depend on it > any more, instead of proactively removing it. I disagree. This is not a good system. This is how you architect an ultraconservative culture that discourages people from fixing things. On Sun, Oct 17, 2021 at 06:32:33AM -0400, James Cloos wrote: > i got hit by the removal of tepfile(1); pv-grub-menu uses it in its > postint script and its removal started blocking my apt upgrades. i had > to copy tempfile over from a virt stuck on an older deb to get around it. > > (cf https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996101) > > it would be useful to ensure no packages rely on something before > removing it... The fix for pv-grub-menu is as follows: ---8<---snip---8<--- diff --git a/update-menu-lst b/update-menu-lst index f2ca1c7..2e01a39 100755 --- a/update-menu-lst +++ b/update-menu-lst @@ -128,7 +128,7 @@ fi # Default options to use in a new config file. This will only be used if $menu_file # doesn't already exist. Only edit the lines between the two "EOF"s. The others are # part of the script. -newtemplate=$(tempfile) +newtemplate=$(mktemp) cat > "$newtemplate" <> $buffer echo "## lines between the AUTOMAGIC KERNELS LIST markers will be modified" >> $buffer echo "## by the debian update-grub script except for the default options below" >> $buffer ---8<---snip---8<--- How much effort is involved with that? I would guess that it is less than bullying me into adding a `tempfile` as a Debian-specific patch to debianutils or bullying me into uploading a `tempfile` package that I do not wish to maintain. On Sun, Oct 17, 2021 at 05:36:25AM -0700, Felix Lechner wrote: > Lintian's last remaining reference to 'tempfile' was dropped. [1] The > updated tag description is now live on our website. [2] Thanks. On Sun, Oct 17, 2021 at 02:33:44PM +0100, Wookey wrote: > I think causing build failures is enough reason to say this. I don't > suppose that mine is the only one. Yes those builds are buggy and > should not do this, and we should make efforts to find out why bazel > (or possibly the build scripts it is operating on) is/are so crappy, > but for now I agree that reverting this is the right thing to do. > > We have time to do this transition properly and quietly in the > background, without causing random breakage. A message about a binary > moving from one package to another does not need to be printed on > every usage of that binary. Indeed it is actively unhelpful to do so. Boyuan packaged GNU which and uploaded it to NEW in August. It is now October, and neither GNU which nor *BSD which nor any other which alternative is in unstable. Presumably one of these could have put a band-aid on your bazel problem, though of course any version of `which` might output things to stderr for a variety of reasons. Lots of things broke between buster and bullseye. Even in stable, people are struggling with horrible i915 driver bugs. Would it have been reasonable to demand that bullseye's kernel be reverted to Linux 4.19 and kept there for 5-10 years until someone figured out the drm issues? My DreamPlug's audio device went from being card0 to card1, breaking everything expecting it to be card0. Would it have been reasonable to revert Linux, ALSA userland, systemd/udev, and whichever other packages until I found the time to figure out what changed and why? Is the difference that these packages aren't Essential? Or that the bug is within the packages themselves instead of a reverse dependency? Or that it involves a package build instead of ordinary operation? On Mon, Oct 18, 2021 at 11:28:52AM +0200, Raphael Hertzog wrote: > Hi, > > On Wed, 13 Oct 2021, David Bremner wrote: > There have been other reports of failures due to the message on stderr, > autopkgtest is not the only one (wookey mentionned a build failure). GNU which can output things to stderr. FreeBSD which can output to stderr. There is no guarantee that cjwatson which won't output anything else to stderr. > In any case, a message saying that which is deprecated when in fact > `which` will stay around (but maintained
Bug#994275: Reverting breaking changes in debianutils
On Sat, Sep 25, 2021 at 11:31:41AM +0100, Simon McVittie wrote: > This seems a good opportunity to ask what I think is a key question here: > what do you consider debianutils' mission to be? The package description uses the phrases "specific to Debian" and "installation scripts of Debian packages". The fact that debianutils is used on non-deb operating systems suggests a failure at the former. The fact that 95% of my inbox consists of hatemail about the interactive usage of `which` suggests a failure at the latter. debianutils should consist solely of utilities that are actually deserving of Essential status, that are maintained by debianutils upstream, and do not needlessly duplicate functionality provided by other sources. Divestiture of mktemp, readlink, sensible-editor, sensible-pager, sensible-browser, tempfile, and possibly mkboot were adjustments toward a better debianutils. mktemp and readlink have been replaced by superior versions. sensible-* live in a non-Essential package in which presumably someone cares about them. tempfile and mkboot are no longer around to confuse people. Did people see these things as progress when they happened? I would imagine that the people who were verbally abusing me and flinging stop energy around at the time did not. Does anyone really miss the old debianutils mktemp now?
Bug#994275: Reverting breaking changes in debianutils
On Fri, Sep 24, 2021 at 03:00:59PM -0700, Sean Whitton wrote: > I thought what you wanted was to drop cjwatson-which, either in favour > of no which in Debian at all, or the option to install GNU or BSD which. > > However, you have now suggested that someone could package > cjwatson-which in another package. But in that case, what do you see > removing cjwatson-which from debianutils as achieving? I am merely pointing out that the current situation allows for an infinite number of people to package an infinite number of `which` alternatives, and no one has to get my permission or coordinate with me. Adrian has suggested that cjwatson-which is superior to any currently proposed alternatives because of its file size. I could not care less which `which` alternatives people want to maintain because I have no use for /usr/bin/which. Picture the happy path: GNU which successfully passes through NEW. A dozen people form a team to package FreeBSD which, which also makes it through NEW. bookworm is released, and debianutils drops cjwatson-which. * Anyone who wants GNU which can install and use GNU which * Anyone who wants FreeBSD which can install and use FreeBSD which * `which` is no longer Essential, so people like me who don't want /usr/bin/which on their systems can have that too, because surely no one competent would choose to have a package depend on `which` when a standard POSIX utility can do a better job * The people who care not a whit about `which` no longer see that annoying deprecation warning being spewed by random scripts * All `which` alternatives in Debian will (probably) be maintained upstream, and also maintained downstream by people that care about `which` * debianutils gets closer to achieving its mission, by having one fewer irrelevant utility that does not belong In this scenario, the GNU which enthusiasts are happy, the FreeBSD which enthusiasts are happy, I am happy, and presumably Adrian is unhappy. So, then, what is the magic solution that will make all four groups happy?
Bug#994275: Reverting breaking changes in debianutils
On Fri, Sep 24, 2021 at 09:26:19AM +0300, Adrian Bunk wrote: > Talking about "which", it might be good to get an explanation from the > maintainer what he wants, and why, and then discuss based on that. What I want is for GNU which to stop languishing in NEW, for the dozen people who keep complaining that FreeBSD which is better and some other volunteer should package FreeBSD which to actually spend the 15 minutes to do the work of packaging it, and if anyone wants to retain what I'll call "cjwatson which", to package that separately as well. Any subset of the above allows me to stop shipping which.debianutils post-release, and hopefully not install any which-providing package on my system. > Both the deprecation message and [1] imply complete removal from Debian, > not only removing it from the Essential set. > > In the message [2] to this bug, the maintainer suddenly does not even > object to having a "which" in another essential package. > > Trying to find a middle-ground proposal has already been attempted. > When the debianutils maintainer mentioned lack of upstream support and > annoyance by requests for additional features a month ago, a maintainer > of sysvinit-utils[3] offered to adopt the existing "which" > implementation there. This would have solved the stated problems - a > maintainer should not have to maintain software he does not want to > maintain. This was rejected with "well, hopefully it's going to stop > being Essential, because it shouldn't be".[4] I understand your confusion here: you seem baffled that I think that this is a terrible idea on several levels but am claiming that I will not use my divine-right-monarch-of-Debian powers to prevent the sysvinit-utils maintainers from maintaining their package. I, in contrast, am baffled that you seem to think I have such powers. > The alternative "which" implementations (GNU and BSD) are 30 kB binaries > instead of the current 1 kB script, enlarging the size of the Essential > set by that much feels like the exact opposite of making it non-essential. I don't have any idea what that means. > Using the alternatives as the debianutils maintainer has now in this bug > suggested in [2] just for moving "which" do a different essential > package (like copying the implementation from debianutils to > sysvinit-utils) sounds unnecessarily complicated, and would require that > the debianutils maintainer fixes the race condition in debianutils when > upgrading from bullseye. The same can be achieved much simpler with a > seamless transfer of "which" to another package as was offered. Certainly going with my original plan would be even simpler, but that would be effectively telling the people that want GNU which and FreeBSD which that they would need to wait a few years before they can have what they want. > In [2] the debianutils maintainer has now suggested that doing > exactly this for "tempfile" would be tolerable for him. Again, I think that this is a terrible idea, that it would annoy me as a user, and that I have no intention of preventing anyone from doing it even if I could. > In my opinion, an amicable middle-ground proposal would be that the > debianutils maintainer completely removes "which" from debianutils, > and assuming the sysvinit-utils maintainers agree, that they adopt > both the existing "which" and (at least temporarily) "tempfile". To use your word, that would be "tolerable". However, I feel compelled to warn the sysvinit-utils maintainers that they may receive a flood of hatemail and be expected to explain to the `which` enthusiasts why their needs and desires don't matter. If they don't care about that, they can start shipping a `which` alternative immediately. I don't think anyone will send them death threats if they ship `tempfile` too. They do not need my permission for these things. > I have not followed all recent discussions around merged /usr, > the TC knows better than me whether action is appropriate regarding > this point or whether it should be discarded. Policy §6.1 hints at why hard-coding paths to binaries is generally a bad idea.
Bug#727708: init system discussion status
On Fri, Jan 03, 2014 at 10:02:01AM -0800, Nikolaus Rath wrote: As said elsewhere, I think there should be a paragraph about packages that depend on a specific init system for reasons other than service startup, e.g. 4. The above criterium also extends to dependencies that are not related to service startup. In jessie, no package may depend on a single initsystem other than sysvinit. After jessie, no package may depend on a single init system other than the default init. or alternatively 4. Packages may, however, depend on a specific init system (which may not be the default init) for features that are not related to daemon startup. Such packages will only be installable on systems running a non-default init, but are permitted in the archive. As loath as I am to participate in this discussion, I have to ask if your intent is to suddenly outlaw all the packages which depend on runit. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140104030651.ga29...@scru.org
in response to Ian's suggestion just now
Yes, I think you should strive for transparency. Thanks. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110725162739.ga27...@scru.org
Bug#573745: Things have changed significantly for the better
On Mon, Jul 05, 2010 at 02:39:58PM -0400, Scott Kitterman wrote: If people had asked to have me fired from a job I was doing (in Debian or elsewhere), you can be certain that sitting down and having a nice chat with them would be very low on my priority list. I would focus my attention on people who were trying to work with me. I believe that's human nature and it would be odd to expect anything else. I apologize; I misunderstood what you were saying. I thought you were talking about properly executing one's job, not having chats. It is in the former case that I find refusing to communicate with people to be unacceptable. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100706134752.ga11...@scru.org
Bug#573745: Things have changed significantly for the better
On Mon, Jul 05, 2010 at 01:45:56PM -0400, Scott Kitterman wrote: I find that doko is perfectly willing to have reasonable discussions with people who are trying to work with him. I don't find it a bit surprising that he doesn't place a priority on dealing with people who are not. He's not always as responsive as I would like, but I'm not always as responsive as others would like either. None of us has unlimited time. Why do you find this to be in any way a reasonable attitude to hold? -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100705180239.ga27...@scru.org
Re: Bug#573745: python maintainance: next steps
On Fri, May 21, 2010 at 05:13:35PM +0100, Ian Jackson wrote: So can I make a suggestion ? How about we have people send in privately names that you think would make excellent candidates. Email them to any TC member and we can pass it on to the other TC members by private email. How does this kind of secrecy serve the best interests of the project? -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100521170752.ga16...@scru.org
Re: Bug#438179: RFC3484 rule 9 active again in glibc 2.7-5.
On Wed, Jan 23, 2008 at 07:41:23PM +0100, Florian Weimer wrote: I'm confused. Was this intentional? There was something resembling a race condition between the reversion of the patch and the upload of 2.7-4. One could say that the change in 2.7-4 was unintentional. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#438179: glibc's getaddrinfo() sort order
On Mon, Sep 24, 2007 at 11:18:00AM +0100, Ian Jackson wrote: COMMON BEHAVIOUR ON TODAY'S INTERNET IS THAT IMPLEMENTED BY GETHOSTBYNAME. Common behavior for gethostbyname() on today's Internet is that implemented commonly in gethostbyname() . How many times do I have to explain this ? getaddrinfo is the REPLACEMENT FOR GETHOSTBYNAME. It is not an interface which applications choose because they want different address sorting behaviour. It is the interface applications MUST USE TO SUPPORT IPV6. I don't think that this is true. getipnodebyname() is an interface applications can use and is much more conducive to drop-in replacement given its interface. I am not recommending use of this function, but your leap of logic is strange. Changing applications to use getaddrinfo instead of gethostbyname is done BECAUSE THOSE APPLICATIONS ARE BEING UPDATED TO SUPPORT IPV6. I think it's done because it's a better, more standardized interface. Updating an application to support IPv6 should not change the way it treats DNS RRsets containing multiple IPv4 addresses. Obviously. Anything assuming what you assume about DNS resolution is going to break in the future eventually. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A comment about RFC 3484 address selection
Juliusz asked me to pass this along to -ctte since non-subscribers can't post. On Sat, Sep 22, 2007 at 10:14:23PM +0200, Juliusz Chroboczek wrote: The semantics of gethostbyname have always been rather vaguely defined. In particular, it has never been clear whether multiple addresses are returned in an order specified by the DNS server, in the order corresponding to local preferences, or in some other order. The only thing that is clear is that the first address returned is the preferred address -- the one that should be used by primitive applications that are unwilling to deal with the complexities of multiple addresses. RFC 3484 clarifies that the list of addresses returned by getaddrinfo is in an order that takes into account both the server's and local preferences. While this might or might not be the best semantics, it is at least a well defined semantics; one that software authors can expect to rely on. Please, do not change standard interfaces in Debian. If you really believe a better interface is needed, please define a new interface under a new name; there is precedent to this approach (e.g. setresuid), which is much better than overloading standard names (e.g. the OpenBSD semantics of setuid, which, while better than the POSIX semantcs, causes useless confusion and grief). Regards, Juliusz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#367709: Call for vote: gcc: requesting libstdc++.udeb
On Mon, Jun 25, 2007 at 05:32:53PM +0100, Ian Jackson wrote: If anyone other than Sven comes up with a good use for a libstdc++ udeb, despite the problems described by others here, then I would like people to give it all due consideration. If the situation changes I'm sure that the d-i team and if necessary the committee are capable of changing their minds. Could someone assert why dependency of a potential partimage udeb is not a good use? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#164889: md5sum FILE produces spurious ` -' in output
* Compatibility with the historical behaviour of md5sum is more important than compatibility with the GNU textutils version. Rather than Debian shipping its own md5sum, why not just rely on the GNU textutils md5sum(1) in coreutils or one of the not-yet-packaged md5(1) utilities from *BSD, depending on whether or not one wants the '-' in output? Historical precedence aside, it seems to me that third-party scripts invoking md5sum will probably want the GNU behavior, and those invoking md5 will want the BSD behavior. The time for changing GNU md5sum's behavior has long passed.
Re: Bug#164889: md5sum FILE produces spurious ` -' in output
Please read my summary of the situation. Debian has been shipping its
own md5sum since at least in August 1994. It's the GNU people who've
made a change to the behaviour.
Yes, and I think that the time to lobby GNU to conform to the Debian
md5sum behavior was long before GNU's md5sum established itself as THE
md5sum. No one uses PGP2's md5sum, and I certainly wouldn't write a
script depending on the Debian behavior.
The time for changing Debian md5sum's behaviour has long passed.
Perhaps, but there's still time to retire it.
Also, you don't address my argument that the original behaviour is
much more convenient.
I don't think it's relevant. However, since you seem to, I will point
out that it's not inconvenient for me at all.
print ${$(print test | md5sum)%% *}
will give me the same result whether md5sum is Debian's historical
md5sum, Debian's rogue md5sum, GNU's md5sum, or an alias to *BSD's md5.
Furthermore, if someone packages a BSD md5, you can get the dashless
output merely by piping to md5(1), which is 3 keystrokes more
convenient.
