Re: [gentoo-dev] category sci-geosciences redundant?

[Georgi Georgiev]

maillog: 17/03/2005-01:58:07(-0800): Robin H. Johnson types
> On Thu, Mar 17, 2005 at 02:33:12PM +0900, Georgi Georgiev wrote:
> > I've been suggesting renaming packages appropriately, but the idea's
> > been shot down with 'We use upstream names' a few times already.
> One unavoidable problem that will come up as a result of renaming
> binaries to avoid collisions, is that if some other package expects them
> by a specific name, it will have to be patched as well (I've seen a
> Makefile that used dev-util/par).

I guess we are talking about slightly different things here. I was
suggesting renaming packages, as in "app-text/par" becoming
"app-text/par-formatter". I never suggested anything about the names of
the binaries, because they have nothing to do with the flatness (or
multilevelness, multicategoriness) of the tree.

This thing about a "Makefile" that uses "dev-util/par" -- I don't get
it.  Did you mean that a Makefile expected /usr/bin/par? That's beyound
my point anyway.

The point that I am making (I think it was clear enough, but why not
state it again) is:

- There is nothing bad in renaming packages, when the short upstream
  names collide.
  
I tried to illustrate it with:

- If installed files are being renamed in order to avoid collisions,
  there is nothing bad in renaming packages to avoid package name
  clashes as well.

The collisions simply helped me prove my point. If Gentoo is going to
call "par" -- the command, not by its upstream name which is
/usr/bin/par but /usr/bin/par-formatter instead, then why should it
insist on calling its package app-text/par and not
app-text/par-formatter? (this is only for illustration).

> > Still, I cannot restrain myself from hacking down your example from
> > above. It's just too good an oportunity to miss. :)
> Congratulations, you've found a bug.
> We keep trying to squash the critters, but they proliferate like crazy.

Oh, it is not a mere bug. It is an *opportunity*! app-text/par is just
begging to be renamed to app-text/par-formatter. If enough devs get
convinced and do that, I'll have my precedent to refer to, when nagging
you about all other duplicate names. And in the end, we get a great flat
tree, with multiple categories and no more 'I am gonna move some stuff
from foo-bar to foo-gaz and break the tree for you', moving directories
in CVS, breaking users' overlays, etc.

> Package collisions like this are actually really hard to detect in an
> automated fashion (without installing every package you want to test).
> We don't have any comprehensive database of the files that a package
> installs (at least that I'm aware of). rpmfind and other databases
> exist for other distros (packages.debian.org has this functionality
> too). This data would probably come up as a by-product of a build
> tinderbox (inside a Xen instance maybe?).

http://www.gentoo-stats.org/ has the information. The database is still
poor, but it will hopefully improve. It had nothing about the "par"s for
example, hence the need to read the ebuilds, which luckily were pretty
clear.

> [snip bug data]
> Would you mind copying this into a bug report, for the appropriate
> maintainers? (they might not be reading this thread)

Alright. Bug #85610 if anyone feels like CC-ing the maintainers.

> > Fix these collisions, and I'll tell you how to fix the problem with
> > their names.
> Actually, we are at somewhat of a chicken and egg problem, as it makes
> it a reasonable amount of sense for the non-colliding package name to
> reflect the name of the binary. I think it would be worthwhile to see if
> there is any sane naming convention other flat-namespace distributions
> have adopted for a package name with collisions, and try to stick to any
> existing name scheme.

I've looked into it (when I was raising the issue before).
Unfortunately, the other distros simply do not have the colliding
packages. Searching for "par" on rpmfind.net found the different rpms
for different distros, but not both app-{arch,text}/par for the same
distro.

> (See for example 'aggregate' and 'aggregate-flim', both packages are
> known as 'aggregate' by upstream - they were developed independently,
> without any knowledge that the other exists. They do roughly the same
> thing, in two very different ways, but still have a slight
> non-overlapping featureset).

-- 
|    Georgi Georgiev   |  Lucas' Law: Good will always win, because    |
|     chutz@×××.net    |  evil hires the _stupid_ engineers.           |
|   [phone]   |                                               |