Re: [gentoo-dev] RFC: new category for container related packages, instead of app-emulation

[Alec Warner]

On Fri, Aug 6, 2021 at 2:12 PM William Hubbs <williamh@g.o> wrote:
>
> On Thu, Aug 05, 2021 at 05:57:06PM -0700, Alec Warner wrote:
> > On Thu, Aug 5, 2021 at 2:44 PM Georgy Yakovlev <gyakovlev@g.o> wrote:
> > >
> > > Hi,
> > >
> > > We've been collecting more and more container related packages in
> > >  app-emulation/*
> > >
> > > What do you think about finally moving those packages to separate category?
> >
> > As always my opinion is that:
> >
> > (a) Categories were a design mistake.
> > (b) The mistake is hard to fix.
> > (c) It's basically low-value to try to 'correctly' categorize packages
> > because of A.
>
> I disagree that categories are a mistake. For one thing, they help with
> situations where different upstream packages have the same name (we have
> two docker packages for example, both named docker by their upstreams),
> and in my opinion they help keep the tree organized. It is nice to be
> able to do something like `ls -d <category>` and check out somewhat
> related groups of packages.

Sure, but you can build a much better mechanism to disambiguate
packages than a category[0].
Grouping packages together is again better served by a different
system. If you want to group packages using categories:

 - A package can only be in 1 group (its category).
 - It's hard to have custom groupings (basically requires I make an
overlay, move the package into a different group, and then do a
pkgmove in my overlay? Does this even work?)
 - Moving packages between groups is not a trivial operation.

>
> I will agree that C above is subjective.
>
> > (d) Recategorizing means a bunch of stuff has to be updated.
>
> All of the updates are much easier to do since we use git, so this isn't
> a concern. You can set this up so it hits the tree all at once.

I think you misunderstand the cost you are imposing on users. Updating
git is the easy part!

You add the pkgmove.
You rewrite some DEPEND atoms.
You bump.

But the impact on *downstream*.

Everyone else who uses those atoms also needs to update them.

For portage-visible names portage will update them (so e.g. it will do
the pkgmove in the VDB, in your binpkg repo, in your metadata, in
/etc/portage/*, world, sets, etc.)
For non-portage visible names you are stuck updating it yourself.

 - Overlays (all need to update their atoms)
 - Any kind of scripts that drive your systems (e.g. "install
foo/bar-123 needs to say 'baz/bar-123' instead")

So my point is that it isn't free. That doesn't mean don't do it; just
understand that it isn't a free operation; or even cheap!

-A

[0] When I say it's a design mistake I am basically talking about
encoding metadata in a name. It's a common design mistake because then
the metadata changes and so does the name. Very common with naming in
computer science. I'm all for names that provide unambiguous packages;
I just want to be able to reference a package in a stable way.

>
> > Do people actually care what category things are in? I just use
> > --search or eix or whatever and the category is just this...bad
> > concept we attach to packages for silly historical reasons..
>
> Yes, I think they are useful like I said above.
>
> So add me to the list of folks supporting recatagorizing the packages.
>
> William