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 \/ /\ [EMAIL PROTECTED] /\ answers, only cross references. /\ \/ +81(90)2877-8845 \/ \/
pgpV1tpgHnZ1Z.pgp
Description: PGP signature
