Re: [gentoo-dev] Re: Re: New category proposal

[Georgi Georgiev]

maillog: 11/05/2005-19:06:37(+0100): Ciaran McCreesh types
> So we end up not using upstream naming, leading to major hassle with
> tarballs, major user confusion and inconsistent naming (why are some vim
> things vim- and others not?). Bad! Now that portage *tells* you when you
> need to be more specific, there's no problem with name matches.

I'll agree with you here. There doesn't seem to be an easy way to decide
what package will get a part of a category in its name. I was going to
propose a "plugins/extensions for an application get the name of the app
prepended + dash", but there would surely be others that will prove me
wrong.

I am giving up on arguing a point that involves too much effort for too
little gain. So, considering that the flat-naming is not feasible (I
cannot counter some of the point that were made against it, the above
being one of them) I'd like to stop shooting out ideas and restate the
problem that I think needs to be solved:

How do we prevent a current category/package combination like
net-wireless/gnome-phone-manager from becoming something else like
app-cellphone/gnome-phone-manager?

More preceisely, what I'd like to see, in order of preference, is

- that package in my overlay that has net-wireless/gnome-phone-manager
  in its *DEPENDs to work for as long as needed
- the net-wireless/gnome-phone-manager that I have in my overlay to
  work for as long as needed
- my net-wireless/gnome-phone-manager binary packages to work without
  having to be "fixpackage"d
- the location of the ebuilds for net-wireless/gnome-phone-manager to
  stay in the same physical path on my filesystem

-- 
\/   Georgi Georgiev   \/ Weiner's Law of Libraries: There are no      \/
/\    chutz@×××.net    /\ answers, only cross references.              /\
\/  [phone]   \/                                              \/