On Tue, 2005-09-20 at 08:54 +0200, Kevin F. Quinn wrote: > 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... >
Technically it does support it if said developer gets Infra to move it server side .... some nasty side effects, etc, but lots better than our current situation where some bright spark removed most if not all history of stuff that was moved :/ -- Martin Schlemmer
signature.asc
Description: This is a digitally signed message part
