Bug#1077764: Ruling request on os-release specification implementation
Hi, I am in favor of your request. On Tue, Aug 06, 2024 at 05:28:57PM +0100, Luca Boccassi wrote: > On Tue, 6 Aug 2024 at 16:43, Helmut Grohne wrote: > > I kindly ask you to stop posting to this bug and mailing list for at > > least 24h from now. Multiple participants have asked you to improve the > > way you interact. I am not seeing such improvement and remind you of the > > Debian Code of Conduct available at > > https://www.debian.org/code_of_conduct. The way you replied to Wouter is > > not respectful and it is not appropriate here. Please distance yourself > > from this matter for a day and reflect. > > Please stop trying to conflate highlighting factual inaccuracies with > "disrespect". There is nothing inappropriate in replying "B is > happening" to "A is happening", when it's B and not A that is > happening. The problem is not WHAT you are saying, it is HOW you are saying it. In those discussions (and you are part of a lot of such discussions) you sound to the casual reader as if you're talking down to somebody you consider a moron, unable to pull up their own pants in the morning. This might be a cultural or language issue because English is a foreign language for both of us, so I am just trying to say how your messages sound for me. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#1077764: Ruling request on os-release specification implementation
On Mon, Aug 05, 2024 at 09:25:31AM +0100, Simon McVittie wrote: > * Some package, let's call it foobar, reads os-release and changes its > behaviour according to whether it sees trixie/testing or unstable > > * foobar_1.2-3 is in unstable and works correctly there > > * The testing migration scripts let it migrate > > * trixie's os-release is different from unstable's (this is the essence > of what Luca is asking for) > > * Unfortunately, when it sees trixie's os-release, foobar_1.2-3 behaves > incorrectly > > * Now our mechanisms to avoid regressions in testing have failed to > prevent a regression, because the regression was never visible to users > of unstable, and in fact didn't exist until foobar migrated That can happen the same way when a package trips over VERSION and VERSION_ID suddenly appearing. While you have a point here, I think that the current state is an expression of us valueing our toolchain and processes higher than the needs of users of testing. By having our development repositories out in the open we are literally inviting people to use it. In fact, that's an important part of our QA. We should not make life harder for those people. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#1077764: Ruling request on os-release specification implementation
On Mon, Aug 05, 2024 at 02:07:54AM +0200, Timo Röhling wrote: > Yet I cannot (painlessly) distinguish a Debian image that > has been created with debootstrap from one that has been created with > mmdebstrap either, and I'm not losing sleep about it. Still it would actually be nice to have an indication somewhere in /etc indicating what software suite (installer, debootstrap, mmdebstrap, live-installer etc) generated the image. Thanks for that idea! > > If trixie was identified as trixie, and sid was identified as unstable, > > what compromise would be, er, compromised, precisely? > Unstable would become less useful at weeding out bugs in packages before > they reach testing, Can you elaborate on that? Why does providing more and better information make it harder to identify bugs? Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#1077764: Ruling request on os-release specification implementation
On Sat, Aug 03, 2024 at 08:07:14PM +0200, Wouter Verhelst wrote: > For what it's worth, I do have one argument in favour of your position. > In the nbd autopkgtest, I need to do a debootstrap of "whatever we are > currently running". That code starts off with "parse os-release", and > then falls back to a horrible horrible perl script that parses > apt-cache policy output if os-release looks like testing or unstable, > because the autopkgtest needs to test the version that we're running, > not "always unstable", and this is just a pain. If os-release were to > distinguish "unstable" from "testing", then I would be able to get rid > of that perl script (and good riddance) I have a very similar problem in my ansible playbooks, with my fleet containing both testing and unstable reference systems AND systems that run testing but will automatically move to stable once testing is released as stable. I would also love to be able to get rid of my heuristics to distinguish testing from unstable. My heuristics are not nearly as ugly as yours, but I would not cry while removing them. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#1077764: Ruling request on os-release specification implementation
On Thu, Aug 01, 2024 at 11:51:45PM +0200, Helmut Grohne wrote: > Conversely, I am unsure how to distinguish testing and unstable myself. > Say I operate an unstable system and eventually decide that my ride is > too bumpy and I prefer running testing, I may edit my sources.list and > after a month or so my system will have reasonably converged to testing. > At what point would my /etc/os-release change? Probably never since the os-release version in unstable would always have to be higher than the one in testing to not confuse dak. But alas, such an unstable-going-testing system will probably never be a "true" testing system since it will continue to keep packages that were removed from testing but not from unstable. Therefore, after the system has "reasonably converged" to testing, the local admin (you) would have to compare package lists anyway, and at this stage an apt --force-downgrade os-release or its working equivalent would be in order. > Russ raised the question of how to represent a testing system that pulls > some packages from unstable. That would stil be a testing system in my opinion. One of the core (mis)features of testing is that you don't get as speedy security support as you get in stable or unstable in most cases. This should be automatically distinguishable. Using apt-pinning it is possible to have a system misrepresent itself in most arbitrary ways, so if you want to be really sure you'd need to look at the versioned set of installed packages, but that's the pain you asked for yourself. > > This has resulted in numerous downstream users, tools, scripts and code > > having to employ fragile Debian-specific hacks, such as trying to grep > > /etc/apt/sources.list in an attempt to catch "unstable/sid" or > > "testing" keywords, which of course is can break spectacularly, for > > example if apt is not configure in an image (which is normal in a read- > > only image-based system), or if both unstable and testing repositories > > are present, with unstable pinned via apt-preferences to 1. Other > > distributions do not have this issue, it is only a problem that Debian > > forces its users to deal with, causing grief and pain. > > Given the issues you experienced, would you be kind enough to reference > some of them here? For example, having ansible playbooks that support testing becoming stable without breaking the systems or having to do in-sync changes to the inventory is unnecessarliy hard and error-prone. > We have a disagreement about whether the information you intend to > convey actually exists beyond the point in time where you deboostrap. If > I debootstrap unstable and look at it a week later, it more closely > represents testing than unstable. Not quite, it would have packages that are not in testing. And if upgraded, it would upgrade von unstable. > Conversely, we might consider that the os-release specification that is > meant to cover the various aspects of Linux distributions is a poor fit > for Debian and that its expressiveness is too limited to accurately > represent the migration-based approach that Debian uses to assemble its > releases. We might consider this a bug in the os-release specification > and we may even disagree with the os-release specification upstream (aka > you) about that. It all depends on how you look at it. I would expect from Debian to work constructively with the os-release specification upstream to adapt the specification that it might be a better fit for Debian some time in the future. If we divert from the specs here, distribution independent tools (like ansible, python, puppet etc) are unlikely to go along and special case Debian. > As far as I read the specification, no field is mandatory. This gives > rise to another solution to come into compliance with the letter of the > specification: Drop the VERSION_CODENAME from /etc/os-release just as > the VERSION is already dropped. As far as I can see, all other fields > have compliant values. That would make the file even less useful than it it today. A classical lose-lose solution. Please don't do that. > I'd like to better understand the problems caused by the imprecise > implementation of the os-release specification as that aspect is still > quite sketchy in your request. Configuration Management, CMDBs, both in heterogenous fleets, using standard software that isn't willing to specialcase Debian. Greetings Marc
Bug#1077764: Ruling request on os-release specification implementation
On Thu, Aug 01, 2024 at 12:06:21PM -0700, Russ Allbery wrote: > The second thing that I'm not fond of is giving testing the version number > 13 when we plan on using 13 as the version number for the trixie release. > I fear that if we do that, someone (probably a third-party package > provider) will add some workaround or behavior change for a package based > on that version number for a problem that only ever existed in testing and > that was not in the actual 13 release. I would instead expect testing to > use some version number that is between stable and the version number that > will be assigned to the next release, to reflect that it is likely to > change substantially before Debian makes an actual release 13. And we cannot even use 13~, since we might release trixie as 12.9 or something. So that decision would have to be taken early by the release team, and it is almost impossible to revert. Does the proposal include lanugage about what to put in the Version: field in debian/control of the proposed package? Would it be pulled in by a versioned dependency (in base-files)? > (If I were designing this from scratch, I'd give serious thought to using > even version numbers for releases and odd version numbers for testing, > similar to how Perl releases are versioned for very similar reasons. But > that's probably too big of a change for the level of benefit.) Using yy.mm as release version number is one of the things that Ubuntu does right. I'd suggest going that path should we decide to touch version numbering. > Presumably the RELEASE_TYPE setting of pre-release is supposed to help > with that, but (a) that variable doesn't seem to be documented in > os-release(5); (b) the sorts of packagers that I'm worried about are quite > likely to not make subtle distinctions like that, so the version is still > there as a potential foot-gun for people who aren't paying close > attention; and (c) I would argue that calling testing a "pre-release" is > not very accurate, since that applies that the contents are very similar > to the eventual release and are in a relatively late stage of testing. Local variables in os_release are unlikely to be picked up by distribution independent tools like ansible and are thus of very limited usefulness. > There's a lot of merit to Santiago's decision to not give unstable a > version number that I think still applies to testing even when it's > considered separately. It would be very nice to not have to do a two-stage distribution comparision in ansible playbooks or such, and to be able to do a numeric comparision. Personally, I currently reference my debian versions on codenames, which puts a lot of distribution specific knowledge about codenames into my playbooks. I am not very fond of that, but it is just a single stage, and it allows me to install new machines on trixie NOW and have them automatically migrate over when trixie becomes stable. I think that I had to define a local variable to accomplish this in my playbooks, but that's a few years in the past. It may be possible easier today. > > There was also a slight variant by Gioele, that again I fail to find now > > and it might be because of the bugs being rearranged, where > > testing-proposed-updates is used to upload testing-specific content. > > That seems like a better approach than the one proposed in the message > above, although I think it requires some manual intervention by the > release team. This doesn't seem like a serious problem given that uploads > are presumably quite infrequent and the package is trivial. For this method to work the package MUST be trivial, if not impossible to get wrong. Greetings Marc
Bug#1077764: Ruling request on os-release specification implementation
On Thu, Aug 01, 2024 at 06:58:09PM +0100, Luca Boccassi wrote: > The TL;DR: ensure that the version of the 'os-release' package with > the content for unstable stays in unstable and never migrates, and the > version of the 'os-release' package with the content for testing goes > to testing either via a quick migration or via > testing-proposed-updates. This also means that os-release NEEDS to be managed in a package that is easy to get bug free: Either automatically generated or so simple that it's impossible to get wrong. The "testing" version of the package that will be promoted to stable on release day will never be in unstable, thus bugs in that package will be fatal immediately. This in my opinion rules out the option of keeping this inside base-files, which is a complex package that I really want to see managed through the normal unstable-testing-stable mirgration process. > That's it. Of course if what you are saying is that you mix and match > a selection of packages from testing and unstable, well that's a > frankendebian - you can do that on any release (I have some testing > packages pulled in my debian stable laptop right now). Hence, on such systems os-release is ALWAYS wrong in one or the other way, hence the local admin is on her own here. I don't see that as a problem. > I could echo "ID=windows 3.1" into my local > /etc/os-release and nothing would stop me or fix it until the next > stable release. Not even automatically. /etc/os-release is a conffile, isnt it? Greetings Marc
Re: /usr-move: Do we support upgrades without apt?
On Thu, Dec 21, 2023 at 11:19:48AM -0300, Antonio Terceiro wrote: > On Thu, Dec 21, 2023 at 10:41:57AM +0100, Helmut Grohne wrote: > > Is it ok to call upgrade scenarios failures that cannot be reproduced > > using apt unsupported until we no longer deal with aliasing? > > I think so, yes. I don't think it's likely that there are people doing > upgrades on running systems not using apt. Do those GUI frontends that work via packagekit or other frameworks count as "using apt"? I now that WE recommend using apt in a text console outside of X, but even many of our own users do what their Desktop Environment does, and our downstreams like *b*nt* recommend other ways to upgrade as well. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#994388: dpkg currently warning about merged-usr systems
On Tue, Mar 29, 2022 at 08:24:50AM +0200, Helmut Grohne wrote: > On Mon, Mar 28, 2022 at 10:24:03PM +0100, Luca Boccassi wrote: > > Also worth noting that a couple of days ago, the author wrote on > > #debian-devel that some time ago the patch was presented to the dpkg > > maintainer, who rejected it with an answer along the lines of the usual > > "usrmerge is broken by design", with no further comment. > > That is unfortunate. If I remember correctly, there was some more > concrete criticism that is still entirely unaddressed in the current > form. > > dpkg is both a Debian package and an upstream project used by multiple > distributions with different needs. Guillem generally cares for the > needs of other distributions. As a result, dpkg separates policy from > mechanism in a lot of places. The patch at hand however fully > intermingles them. Which directories are to be aliased could be a > vendor-specific configuration and should be encoded as such. That kind > of separation of concerns has not happened at all. The easy way to get out of that would be to generalize the issue, probably somewhere along the line of having a configurable (sic!) list of lists of directories that are to be treated equally. Unfortunately, my programming skille as nowhere as good as that I would dare to lay my hands on a C program as important as dpkg. > > So, what is the next step? Will the those on this thread who asserted > > they think a correct patch would be accepted without issues try and > > take it forward themselves? > > I don't think anyone claimed that incomplete patches would go in without > issues. Much to the contrary. My experience with sending patches to > dpkg is that they do go through multiple rounds due to high quality > feedback. The problem I see here is that communication between patch > author and dpkg maintainer does not work and thus no progress is being > made. To be honest, the current form of the patch is a testament of how > poorly the /usr-merge proponents have spent the last five years on an > issue that was known for more than ten years. Communication with the dpkg maintainer is sometimes difficult. I remember having some issues with the --path-exclude option that were so bizarre that I didn't even grok whether this was a code or a documentation issue, getting terse answers to my question and eventuell no answers at all. I eventually stopped using the feature, and frankly, have given up on understanding dpkg entirely. I am writing this because I understand that being a package maintainer is not only about technical skills such as coding and documenting, it is also a communicative challenge, and when you're maintaining a core program like dpkg is, you need to be even more communicative because so many people want things from you. It is not the smartest idea to lock yourself in the cellar and just communicate by doing software releases. > There is a social aspect here that is presently failing hard. Yes :-( Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#914897: debootstrap, buster: Please disabled merged /usr by default
On Sun, Dec 02, 2018 at 07:54:39PM +, Simon McVittie wrote: > I would encourage anyone with questions about the behaviour of merged and > unmerged /usr systems to try them, either by building one chroot, container > or VM with merged /usr and one without, or by building a chroot, container > or VM with unmerged /usr, copying it, and installing usrmerge in the copy. That would give me an impression about how things are today. > The answer to your question is that non-/usr-merged systems behave the > same way they always have: binaries end up wherever the source package > chooses to put them when it builds the .deb (typically determined by > where they appear under debian/tmp). The next debhelper change might choose to give / instead of /usr as a target directory by default, moving hundreds of megabytes from /usr to / over time. My question was about the distant future, and not the current snapshot of things. And, it has been satisfactorily answered by now. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#914897: debootstrap, buster: Please disabled merged /usr by default
On Sat, Dec 01, 2018 at 11:36:45PM +0100, Didier 'OdyX' Raboud wrote: > Le samedi, 1 décembre 2018, 19.29:59 h CET Marc Haber a écrit : > > Will binaries move from /usr/bin to /bin? Or will binaries move from > > /bin to /usr/bin? > > A merged-/usr has a /bin → /usr/bin symlink; so a .deb package unpacking > /bin/grep will make that binary end up in /usr/bin/grep; but the > /bin → /usr/bin symlink ensures that you can either access /usr/bin/grep > directly or /bin/grep through the symlink. And where will the binaries and up on an un-usrmerged system with a dedicated /usr? in /usr, I hope? Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#914897: debootstrap, buster: Please disabled merged /usr by default
On Sat, Dec 01, 2018 at 07:20:57PM +0100, Didier 'OdyX' Raboud wrote:
> * Currently, according to my `apt-file`, 259 binaries are shipped in /bin
> directly, accross 85 packages. (for /sbin, 597 binaries for 190 packages).
This might sound like a stupid question, what will happen when a package
built on a usrmerged System will be installed on a non-usrmerged system?
Will binaries move from /usr/bin to /bin? Or will binaries move from
/bin to /usr/bin?
The former is likely to cause fun on upgrades, since root file systems
on systems that were installed with /usr on its own partition tend to be
rather smallish. Dumping the entire former content of /usr/{bin,sbin} to
/{bin,sbin} is likely to wreck those systems, most of them probably
being either embedded or in big datacenters where people usually don't
waste disk space for root file systems.
Greetings
Marc
--
-----
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: Package-created usernames
On Tue, Dec 04, 2007 at 08:52:34PM -0700, Bdale Garbee wrote: > The second is whether it's acceptable for a Debian package to *require* a > specific username. There seems to be at least an implication that if the > namespace clash potential is eliminated or significantly reduced, that this > would remove the need for supporting configurability of the username used by > a package or set of packages. I'm very concerned about this, since I believe > that no matter how well we solve the namespace potential collision problem, > there will always be users of our packages in large installation environments > who have already made decisions about their username namespace that they want > Debian systems to be able to "fit in to" without requiring rework or > recompilation of packages. CAN OF WORMS DANGER AHEAD! BEWARE! The user name is likely to be spread out through build-time, installation-time and run-time scripts in the package. Since one cannot easily build includes in maintainer scripts, one would probably need to _generate_ the maintainer scripts at package build time, introducing gazillions of "interesting" bugs. Please, don't open that can of worms, and settle on a naming policy which minimizes impact, such as the "Debian-" prefix that Debian's default MTA has been using for years. I am sure that we'd know by now if this had made trouble anywhere. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#412976 repoened - reassign tech-ctte (mixmaster /etc/default/*)
On Sat, Dec 01, 2007 at 07:34:58PM +0200, Jari Aalto wrote: > >From Admin's point of view dealing with symlinks is much more > uncomfortable to control the initial start/stop status. If one is not comfortable with a sysvinit scheme, one should not be adminning a Debian system. Alternatives (such as file-rc) are available, and while update-rc.d is strictly speaking only geared to be used from maintainer scripts, it can also be used as a tool for the local admin. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: Bug#399859: nagios2 uses images from nagios-images, but has no recommends or suggests]
Ok, off into wasting even more time that could be better spent. On Wed, Dec 20, 2006 at 02:43:05PM +0100, Henning Sprang wrote: > See the discussion in > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=399859 > > As the package maintainer request I do so, I didn't request that, I suggested it. > and does not seem to be interested in communication of any type about > the issue, after I explained my position, I try to talk to you. I explained my position, and happen to disagree with the submitter. > The nagios web interface looks broken when the images are missing. We are currently planning to split off the web interface off the main nagios2 package from the web interface post-etch, as a nagios daemon might be useful as scheduler for a host that delivers passive service checks. The web interface package will have a stronger dependency to nagios-images. Currently, the intention is to keep the dependencies small as nagios2 might be installed on hosts that do not need all bells and whistles. I therefore think that suggests is the appropriate degree of dependency. > This gives users a feeling of broken and not correctly working > software. This is a bad usability issue. Tehy are in no plave > informaed about this being a consequnece of leaving the optional > nagios-images package out, which is only a suggest dependency. > > This, in turn, makes a bad experience of Debian and it's software. The submitter is vastly exaggerating. > In Upstream, also the distribution is not intended to be installed > without images. In Upstream, the software is not meant to be packaged at all. > P.S.: Adding the tag "wontfix" is incorrect. The definition does not > match, because, not having the images is not one possible way, but one > that makes the application look broken. The application just runs fine without the images. > This is a usability issue. And there's no evidence that resolving > this issue causes worse problems or breaks something else. It is going to waste a lot of disk space on systems that do not use the web interface. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
