Ungoogled-chromium: What is a "platform"?

[PF4Public]

I was always wondering, whether I should create a "platform repository" for Gentoo under ungoogled-software... What is a "platform" after all?
Related to e41b98f

[Eloston]

That's a good question. I don't know how to give a precise definition for it, but I'll try to describe it:

The term "platform" grew out of how people wrote build/packaging scripts for Chromium.

"Platform" used to simply be the term as people in the computing field used it. Windows and macOS systems are pretty homogeneous across their user base, so both of those systems have one set of build scripts.

However, the situation becomes more complex once we consider the world of UNIX-like systems, notably Linux-based. In that case, it seems like "platform" more closely matches a Linux distribution, because each distro should have one set of build scripts. This works for most popular Linux distributions that we know of. But there are exceptions too: Portable Linux, GNU Guix, Flatpak/AppImage/Snap, etc.

I think as long as your system needs a different set of build scripts from what is already out there, then it's probably a different platform.

Maybe there's a better term to use here? Maybe we should be more restrictive in what we consider a "platform"? Suggestions welcome.

[wchen342]

This is hard to say. Generally the thing is hierarchical IMO. First we have desktop and mobile operating systems. Then for desktop systems, we have Win, MacOS, Desktop Linux and some others. For mobile systems we mainly have IOS and Android. Then for Desktop Linux we have a lot of distributions: Archlinux, Debian-based, Gentoo, etc. Finally within each family of distributions we have variants, for example Debain-Ubuntu, Arch-Manjaro, etc.

[PF4Public]

Would a term "environment" better describe it? So, that we write in readme something like this: "Ungoogled-chromium could be built under various environments", "Building under Windows environment", "Building under MacOS environment", "Building for portable Linux environment" et cetera. And instead of "platform repo" we say "Windows-specific repo" and so on.

What you think?

[Eloston]

And instead of "platform repo" we say "Windows-specific repo" and so on

How would we refer to the collection of all repos that provide support for environments?

[wchen342]

And instead of "platform repo" we say "Windows-specific repo" and so on.

But how to refer to those repos for linux distributions?

[PF4Public]

How would we refer to the collection of all repos that provide support for environments?

"Ungoogled-chromium could be built under various environments. There are some community maintained target-specific repositories under ungoogled organization". Or the like.

I have difficulty imagining. In which context do we need to call them collectively?

But how to refer to those repos for linux distributions?

"Debian-specific", "Arch-specific". Someone interested in Arch, will easily guess, which repository is targeted at Arch. This way we use less words actually, that is: neither environment nor platform. Less words - better clarity.

Oh by the way "Arch-targeted repository" "Portable Linux-targeted repository" are also good names, though longer ones.

[Eloston]

I have difficulty imagining. In which context do we need to call them collectively?

In documentation I've mentioned "platform repos" to refer to such a collection. I use it more often than others because I'm managing all of them. One notable example is docs/repo_management.md that caused you to create this issue to begin with.

"Debian-specific", "Arch-specific". Someone interested in Arch, will easily guess, which repository is targeted at Arch.

Those are adjectives without a noun, and I think that's a bit confusing.

Oh by the way "Arch-targeted repository" "Portable Linux-targeted repository" are also good names, though longer ones.

This is better, but it seems to be no shorter than "Debian platform repo" or "Debian environment repo" at that point.

Maybe "Debian-specific repo" and "Arch-specific repo" would work. In fact, I think "Debian repo" and "Arch repo" are clear enough in deeper discussions.

Another idea would be to write debian.git or archlinux.git, as reference to their git repo URLs.

[wchen342]

Maybe it is a little late to say this but I just realized, why not just call them OS? Because essentially every one of them discussed is an OS. And then we can call each sub-repo by the OS name directly.

[Eloston]

Because essentially every one of them discussed is an OS

I'm having troubles fitting that to Portable Linux, GNU Guix, Flatpak/AppImage/Snap (technically part of Portable Linux, for now). But if these are the only exceptions, it might be fine to ignore them.

And then we can call each sub-repo by the OS name directly.

Could you clarify what you mean by that? If I wanted to refer to ungoogled-chromium-debian, should I just say "Debian"? Or are you suggesting something like "Debian repo", "Debian OS repo", or "Debian OSR"?

[wchen342]

I'm having troubles fitting that to Portable Linux, GNU Guix, Flatpak/AppImage/Snap (technically part of Portable Linux, for now). But if these are the only exceptions, it might be fine to ignore them.

I think technically Guix is a distribution. Flatpak/AppImage/Snap are exceptions but they can hardly be called "environment" or "platform" anyway so there is really no good way to refer to them I think. Maybe "standalone linux installer" (comparing to Windows Installer).

Could you clarify what you mean by that? If I wanted to refer to ungoogled-chromium-debian, should I just say "Debian"? Or are you suggesting something like "Debian repo", "Debian OS repo", or "Debian OSR"?

What I had in my head was "Debian repo", because everyone know the exact name and there will be no need to put them into a category like "environment" or "platform".

[mbakke]

I believe the majority of Guix users are on non-Guix distributions. Guix is more of a "software environment manager" that happens to have an OS built on top of it.

The next version of Debian will likely ship with both Guix and Nix, diluting the distinction.