1 |
On Mon, 12 Jun 2006 19:26:18 -0400 |
2 |
Alec Warner <antarus@g.o> wrote: |
3 |
|
4 |
> > * Portage must provide a way for external programs to obtain a list |
5 |
> > of all repository identifiers for a given system. It is assumed |
6 |
> > that this will be in the form of a ``portageq`` command (e.g. |
7 |
> > ``portageq get_repo_ids``). |
8 |
> > |
9 |
> |
10 |
> not done, and if we implemented it, would be a hack (although |
11 |
> compromisable in this scheme, would be essentially a fake portageq |
12 |
> command)anrRokydtysyyetntgsI |
13 |
|
14 |
> |
15 |
> > * Portage must provide a way for external programs to obtain the |
16 |
> > base path for a repository with a given ID. It is assumed that this |
17 |
> > will be in the form of a ``portageq`` command (e.g. ``portageq |
18 |
> > get_repo_root gentoo-x86``). |
19 |
> |
20 |
> same as above |
21 |
> |
22 |
> > |
23 |
> > * Portage must extend ``portageq has_version`` to support |
24 |
> > restrictions to a given repository ID. |
25 |
> |
26 |
> and again |
27 |
> |
28 |
> > |
29 |
> > * Portage must extend ``portageq`` to implement a command which |
30 |
> > returns whether or not the profile used for a given repository ID |
31 |
> > is exactly the given profile (e.g. ``portageq profile_used |
32 |
> > default-linux/sparc/sparc64/2004.3 gentoo-x86``). |
33 |
> |
34 |
> and again |
35 |
> |
36 |
> > |
37 |
> > These extensions are assumed during the following specification. |
38 |
> > |
39 |
> |
40 |
> I have no problem with basically writing up 'fake' portageq calls. |
41 |
> However often people tell me overlays are important, they don't serve |
42 |
> as multipile repos and don't have metadata/news, so they are excluded |
43 |
> in this specification (intentially?). Portage doesn't do multiple |
44 |
> repo's so any repo-related call will be a 'fake' one, that just |
45 |
> returns the expected data, unless someone has a better method (looks |
46 |
> at other portage devs). |
47 |
|
48 |
I was assuming that given Portage's current lack of multiple repository |
49 |
support it would simply look to existing settings for all of these. The |
50 |
name can be grabbed from profiles/repo_name which already exists; the |
51 |
path can just return $PORTDIR if the name matches and error if not; the |
52 |
repository restrictions for has_version can simply be ignored, and the |
53 |
profile can check /etc/make.profile. |
54 |
|
55 |
|
56 |
> I am not sure if I pointed this out before, but I feel that news |
57 |
> items should be of a pragmatic nature. IE they should be useful but |
58 |
> not frequent. It should not be overly difficult to post a news item |
59 |
> for a particular incident. If news items are constantly being shot |
60 |
> down due to "importance" or some other reason that lacks what I would |
61 |
> call a reasonable blocking reason ( ie bad grammar, clarity problems, |
62 |
> inaccuracies ) it will discourage developers from submitting them. |
63 |
> While I am against completely crap news items, I would rather see |
64 |
> more news items than very few. |
65 |
|
66 |
While I don't like to appeal to common sense, given the ability to |
67 |
filter displaying of items based on profile, package installed, etc, it |
68 |
should be fairly easy to avoid flooding people with irrelevant news |
69 |
items without raising the bar so high that it discourages people. |
70 |
-- |
71 |
gentoo-dev@g.o mailing list |