Am Donnerstag, dem 11.03.2021 um 08:09 +0100 schrieb Reto:

It's not the same context...

A "fork" is an eating utensil that you use to shove food into your mouth. However, a "fork" is also a software project that is based of some prior work. It's also a point where a road diverges into two paths...

See the point I'm trying to make?

It isn't particularly confusing, it's simply not the same context. Words can (and do have) different meaning based on it.

Your example is not valid. Because the two different definitions of an orphan are within the same context: arch package management. Depending on which repo you are getting the package from an orphan is this or that. That is ambigious.

On 2021-03-11 at 09:11:34 +0100, Reto via arch-general wrote:

On 11 March 2021 08:54:16 CET, Matthias Bodenbinder wrote:

...

Your example is not valid. Because the two different definitions of an orphan are within the same context: arch package management. Depending on which repo you are getting the package from an orphan is this or that. That is ambigious.

Except it really isn't the same context...

The AUR is a repository for package recipes, the build files only.

If you look at the definition you gave from pacman

orphans - packages that were installed as dependencies but are no longer required by any installed package.

That makes absolutely no sense for a build recipe, it simply can't refer to the same thing. You don't install pkgbuild instructions and a repo of those doesn't have things installed.

Suppose I install packages big-application and useful-library from AUR, and big-application depends on useful-library. Then I uninstall big-application, and useful-library's maintainer abandons it. Now useful-library on my system is a orphan under both definitions, so if all I say is that useful-library is an orphan, then the context to which I am referring is, in fact, ambiguous. Often, though, the context is given by, well, the context of my statement.

So no, package building and package installation aren't the same context, even if related.

On Thu, Mar 11, 2021 at 3:51 PM Matthias Bodenbinder via arch-general < arch-general@lists.archlinux.org> wrote:

It is simply confusing and not best practise to take a defintion from pacman (which was first in line from my point of view) and overwrite it with a new definition for the AUR. And then explain the users: "Well that is how it is. An orphan can be this or that in the Arch world. You just need to understand the context."

I dont get why someone wants to have it that way.

Because both meanings of "orphaned" existed before and outside of Arch and you're asking for us to invent new terms.

Am Donnerstag, dem 11.03.2021 um 16:15 +0100 schrieb Lars Gustäbel:

I really don't know what you're trying to prove here. I would be interested in which words you would propose to distinguish between the two contexts.

The pacman defintion is a local definition which only applies to an individual PC. If I have an orphan package on my PC, it is not neccessarily an orphan on your PC. The AUR definition of orphan is a global definition. Meaning, an orphan AUR package is orphan for everybody. I would distinguish this use case by calling it "abandoned" instead or oprhan.

Den tors 11 mars 2021 16:46Lars Gustäbel via arch-general < arch-general@lists.archlinux.org> skrev:

On Thu, Mar 11, 2021 at 04:24:49PM +0100, Matthias Bodenbinder wrote:

...

Am Donnerstag, dem 11.03.2021 um 16:15 +0100 schrieb Lars Gustäbel:

...

I really don't know what you're trying to prove here. I would be interested in which words you would propose to distinguish between the two contexts.

The pacman defintion is a local definition which only applies to an individual PC. If I have an orphan package on my PC, it is not neccessarily an orphan on your PC.

The AUR definition of orphan is a global definition. Meaning, an orphan AUR package is orphan for everybody. I would distinguish this use case by calling it "abandoned" instead or oprhan.

Yes, "abandoned" is good indeed. Although, I would prefer to have orphan packages on my system be called "unneeded" packages. It is much more precise in my opinion.

I also think, completely irregardless of the double usage question and how you can either think of it as problematic or not depending on how narrow contexts you consider, that the term in AUR should be changed. I suggest "unmaintained" though. I think "unneeded" instead of "orphan" for the pacman context sounds good too, but have no strong opinion. Elvis

-- Lars Gustäbel lars@gustaebel.de

This is really only an issue for non-fluent English speakers. We have to cater towards one language or terms get confusing and on the other end overly verbose. Both usages of orphan (aur, and packages) match conceptual categories for the term, meaning abandoned. They're each just abandoned in different senses. For simplicity sake I would not suggest going into the nuances of different words meaning different types of abandonment. You'll just end up splitting hairs and progress towards complicating the terminology for rather simple package maintenance, while adding no new package management features. On Fri, Mar 12, 2021 at 2:19 AM Óscar García Amor via arch-general < arch-general@lists.archlinux.org> wrote:

El jue, 11 mar 2021 a las 17:40, Elvis Stansvik via arch-general () escribió:

...

...

Yes, "abandoned" is good indeed. Although, I would prefer to have orphan packages on my system be called "unneeded" packages. It is much more precise in my opinion.

I also think, completely irregardless of the double usage question and how you can either think of it as problematic or not depending on how narrow contexts you consider, that the term in AUR should be changed. I suggest "unmaintained" though.

Agree. Is better definition, "abandoned" can create confusion and you can think that is "abandoned" by upstream, but "unmaintained" takes the point.

...

I think "unneeded" instead of "orphan" for the pacman context sounds good too, but have no strong opinion.

Or "unnecessary".

Greetings.

-- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me

Am 12.03.21 um 14:39 schrieb Lukáš Kucharczyk via arch-general:

I think making the terminology clearer is a benefit to English speakers at all levels of language mastery.

Calling the things what they are, that is unmaintained package and unneeded package, is an overall improvement to clarity, and also sidesteps the confusion stemming from one word meaning something different in different but adjacent contexts.

In the local case, "unneeded" may be too strong. It is possible a package has been installed as a dependency and later you started to use its commands directly. If you remove the package depending on it now, it is not unnecessary. I think orphaned covers that case well, the final action may be removal if the package is truly unneeded or a promotion to explicitly installed status.

Em março 16, 2021 12:35 Maxim Vuets via arch-general escreveu:

In spite of the backlash that Matthias has got, I think he has a point. Yes, the contexts are different (dependencies and ownership), yet they are related (packages). Mind the curse of knowledge[1]: it's pretty clear what an orphan means once you know what it means, so perhaps it does not hurt to add a bit more clarity for newcomers.

In my mind, the pacman term "orphan" fits no longer required leftovers well, because it deals with hierarchy and dependencies. On the other hand, the AUR's "orphan" has less to do with parents, but more with owners, maintainers (and caregivers?). Perhaps, semantic synonyms like unowned, unmaintained, disowned would be better suited.

Now, a price and whether to change the existing terminology is a completely different matter of discussion.

Maxim's 2¢.

[1] https://en.wikipedia.org/wiki/Curse_of_knowledge

I think enough shed discussion happened already. Why don't the proponents actually go out and try to paint it? The projects involved here, pacman, archweb and aurweb are all open source and can receive patches. Regards, Giancarlo Razzolini

On 3/16/21 1:19 PM, Matthias Bodenbinder via arch-general wrote:

Am Dienstag, dem 16.03.2021 um 12:47 -0300 schrieb Giancarlo Razzolini via arch-general:

...

The projects involved here, pacman, archweb and aurweb are all open source and can receive patches.

I would suggest that the Arch community agrees on the topic first before starting multiple parallel discussions within sub communities of developers of tools.

With a community agreement as a backup it is much easier to create change requests for the individual tools.

I believe the suggestion was, with a change request that includes a working code implementation, people are more likely to care. It's not just a documentation change, e.g. the AUR and the archweb website would need various code changes including renaming part of the database schema, changing the search API, etc. Do you know how much work it might take to change this? Do you know how much API might potentially be broken by such a change? -- Eli Schwartz Bug Wrangler and Trusted User

Am Dienstag, dem 16.03.2021 um 19:03 +0100 schrieb Georg via arch- general:

Make a proposal at the relevant places or leave it, but this topic has made enough noise on this list.

Love it or leave it? I will leave it.

How I look at this I'd it's a lot like vim. We can either optimize to make things easier for newbies, or more efficient for experienced users. Based on context, it's easy to understand, and you're keeping things simpler by not coming up with myriad additional terms for related but slightly different concepts, with no benefit for the end user or developers. On Tue, Mar 16, 2021, 2:45 PM Giancarlo Razzolini via arch-general < arch-general@lists.archlinux.org> wrote:

Em março 16, 2021 16:22 Matthias Bodenbinder via arch-general escreveu:

...

Am Dienstag, dem 16.03.2021 um 19:03 +0100 schrieb Georg via arch- general:

...

Make a proposal at the relevant places or leave it, but this topic has made enough noise on this list.

Love it or leave it? I will leave it.

So, what was the point behind all this bikeshedding if, at the first criticism, you drop it? I told you to try and use the new RFC system to get this moving. But, I'm telling you right now, Arch has way more difficult to tackle issues than "what should the semantics on packages be".

Regards, Giancarlo Razzolini