1 |
On Tue, 2005-09-20 at 08:54 +0200, Kevin F. Quinn wrote: |
2 |
> On 20/9/2005 7:37:19, Georgi Georgiev (chutz@×××.net) wrote: |
3 |
> > maillog: 20/09/2005-07:21:08(+0200): Christian Parpart types |
4 |
> > > On Monday 19 September 2005 15:22, warnera6 wrote: |
5 |
> > > > Mark Loeser wrote: |
6 |
> > > > > Paul de Vrieze wrote: |
7 |
> > > > >> I think that dev-util is a very specific category containing |
8 |
> > > > >> development utilities of some sort. There might be some |
9 |
> > > > >> misclassifications in them, but from a user perspective I don't |
10 |
> > > > >> really care about the language anything is written in. As C++ is so |
11 |
> > > > >> widespread I don't think that anything but app-misc or the like |
12 |
> > > > >> should be moved into a dev-cpp category. |
13 |
> > > > > |
14 |
> > > > > This isn't for what the package is written in, but more for what the |
15 |
> > > > > package is for. If the package is a utility for use when doing |
16 |
> > > > > coding with C++, like the ones I listed, then I think it should be |
17 |
> > > > > in dev-cpp. That's what the metadata for the category describes it |
18 |
> > > > >to be. |
19 |
> > > > > Mark |
20 |
> > > > |
21 |
> > > > Once again I'd like to point out that organizing packages in the tree |
22 |
> > > > by category is a stupid idea for this very reason. |
23 |
> > > |
24 |
> > > and what's *your* certain proposal then? |
25 |
> > |
26 |
> > That's been discussed a number of times already. The best idea is to |
27 |
> > leave the categories alone and forget that the category means anything. |
28 |
> > Or, to throw the ball back in your court, could *you* suggest |
29 |
> > alternatives that accomplish the following: |
30 |
> > |
31 |
> > (quoting [1]:) |
32 |
> > |
33 |
> > More precisely, what I'd like to see, in order of preference, is |
34 |
> > |
35 |
> > - that package in my overlay that has net-wireless/gnome-phone-manager |
36 |
> > in its *DEPENDs to work for as long as needed |
37 |
> > - the net-wireless/gnome-phone-manager that I have in my overlay to work |
38 |
> > for as long as needed |
39 |
> > - my net-wireless/gnome-phone-manager binary packages to work without |
40 |
> > having to be "fixpackage"d |
41 |
> > - the location of the ebuilds for net-wireless/gnome-phone-manager to |
42 |
> > stay in the same physical path on my filesystem |
43 |
> > |
44 |
> > end quote |
45 |
> > I would grade the above features as "vital", "badly needed", "happy to |
46 |
> > see it done", "cosmetic". I.e., even solving only the first one is |
47 |
> > enough, though if you could get to number two it would be better. |
48 |
> |
49 |
> |
50 |
> Here's another requirement I'd like to add to the list: |
51 |
> |
52 |
> - when moving stuff around, change history moves too |
53 |
> |
54 |
> CVS doesn't support this, but subversion does (along with atomic commits, |
55 |
> also useful to ensure integrity of the tree during a move). The support |
56 |
> for symlinks in subversion may also provide a way to resolve the overlay |
57 |
> problem... |
58 |
> |
59 |
|
60 |
Technically it does support it if said developer gets Infra to move it |
61 |
server side .... some nasty side effects, etc, but lots better than our |
62 |
current situation where some bright spark removed most if not all |
63 |
history of stuff that was moved :/ |
64 |
|
65 |
|
66 |
-- |
67 |
Martin Schlemmer |