On 20/9/2005 7:37:19, Georgi Georgiev ([EMAIL PROTECTED]) wrote: > maillog: 20/09/2005-07:21:08(+0200): Christian Parpart types > > On Monday 19 September 2005 15:22, warnera6 wrote: > > > Mark Loeser wrote: > > > > Paul de Vrieze wrote: > > > >> I think that dev-util is a very specific category containing > > > >> development utilities of some sort. There might be some > > > >> misclassifications in them, but from a user perspective I don't > > > >> really care about the language anything is written in. As C++ is so > > > >> widespread I don't think that anything but app-misc or the like > > > >> should be moved into a dev-cpp category. > > > > > > > > This isn't for what the package is written in, but more for what the > > > > package is for. If the package is a utility for use when doing > > > > coding with C++, like the ones I listed, then I think it should be > > > > in dev-cpp. That's what the metadata for the category describes it > > > >to be. > > > > Mark > > > > > > Once again I'd like to point out that organizing packages in the tree > > > by category is a stupid idea for this very reason. > > > > and what's *your* certain proposal then? > > That's been discussed a number of times already. The best idea is to > leave the categories alone and forget that the category means anything. > Or, to throw the ball back in your court, could *you* suggest > alternatives that accomplish the following: > > (quoting [1]:) > > More precisely, 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 > > end quote > I would grade the above features as "vital", "badly needed", "happy to > see it done", "cosmetic". I.e., even solving only the first one is > enough, though if you could get to number two it would be better.
Here's another requirement I'd like to add to the list: - when moving stuff around, change history moves too CVS doesn't support this, but subversion does (along with atomic commits, also useful to ensure integrity of the tree during a move). The support for symlinks in subversion may also provide a way to resolve the overlay problem... -- [email protected] mailing list
