DDI: change suffix to .gpt #89
Conversation
Follow-up to 68dd1d9: the extension ".raw" is not ideal: - it is too generic: there are simply too many things which are "raw", and different people will have different expectations, and an extension should be unique. - a DDI is not actually "raw". It has a header with a partition table, so it's a well-defined binary container format. "Raw" would normally be used for file with just contains unadorned data, without a header or other means of understanding the contents without context. Once you take the exact same data, but wrap a header around it that describes the data, the file contents are not "raw". Semantic Line Breaks à la https://sembr.org/ are used.
|
Nonono very hard no. I just spent ~4 years switching everything from what I had before to .raw as @poettering wanted (it's not even fully finished yet). It required an astonishing amount of work from several departments and groups. I am not going to switch again. |
|
That's why such things should be discussed publicly first. When an implementation is created internally, then it's subject to change later. But anyway, I don't think you actually have to change anything internally. This is just a recommendation after all, and you can use |
|
It was discussed publicly, on various systemd PRs and issues. Not here obviously because this org didn't even exist at the time. But it is the standard now and it cannot change, as it's an established API. |
Of course it can be changed. The old suffix would have to be honoured, but that's no problem. (I think that in most places we don't care about the suffix at all, but there are some places where we enumerate things.) As far as transitions go, this should be a very easy one. |
|
No, because then tooling would start to drop support for the existing one, or new tooling would not even add it, breaking all existing use cases, for example all image creation tools would stop using the existing suffix and create incompatible images. |
|
We had this discussion back at LPC in Dublin last year already, with you @keszybz. Back then we already more or less came to the conclusion that the ship has sailed on the .raw suffix, it's too much established already, and our codebase only cares for that suffix, for example the code in src/shared/discover-image.c only knows how to deal with that suffix, and so does nspawn and so on. (they'll take file wit any suffix, but only if the suffix is .raw know how to chop it off correctly to get a default hostname and such) Our compromise back then was to introduce secondary suffixes though, i.e. I added code for dealing with these secodnary suffix to discover-image.c in the past months btw. I think with v255 we should be reasonably complete on that. the uefi forum people registered with IANA that GPT disk images should have a mime type of "application/vnd.efi.img" btw, and at the same time registered a suffix for the files:
XDG shared-mime-info (i.e. the thing file manages on gnome/kde/… use to identify file types) implements the IANA definition btw. I recently filed this to make this more compatible with our images: https://gitlab.freedesktop.org/xdg/shared-mime-info/-/merge_requests/276 Anyway, I think we should stick to the At the same time we should continue to support image names without the secondary suffixes, with only primary suffix to support multi-modal images, i.e. images that are both confext and sysext, or images that are both portable services and OS images. |
|
We might want to define proper mime types for our secondary suffixes btw (not for .raw, because too generic), maybe even register with iana, but I am too lazy for that bureaucracy, and just use one of those x mime types |
|
Yeah, we discussed this and I regret not pushing harder against this extension. I didn't realize that this will be visible in so many places. As long as this was internal to our implementation, it didn't matter so much. But documenting this as the one and only extension makes this more visible and problematic.
(FWIW, the description on the iana page is terrible: it doesn't even mention GPT anywhere.)
OK, so if |
|
So I am not convinced this is really necessary, but I am also not totally against it, if these suffixes are supported as an alternative in our codebase. But please prep the systemd commit for this at the same time, as I am really not a fan of specs that have no footing in reality. |
|
If you add alternatives, it adds to the confusion, and you start getting things that implement one and not the other. Given it's a cosmetic thing and it has shipped already, I don't think it brings in much value, but just increases the chances things will stop working one way or the other. For example, if you are on existing versions of systemd, you won't be able to load any of these. It will get confusing for developers and confusing for users. |
|
.gpt is not a great suffix btw, .ddi would be much better. but still, I am not convinced this all is really necessary. |
Follow-up to 68dd1d9: the extension ".raw" is not ideal:
Semantic Line Breaks à la https://sembr.org/ are used.