On Mon, 12 Jun 2006 19:26:18 -0400 Alec Warner <[EMAIL PROTECTED]> wrote:
> > * Portage must provide a way for external programs to obtain a list > > of all repository identifiers for a given system. It is assumed > > that this will be in the form of a ``portageq`` command (e.g. > > ``portageq get_repo_ids``). > > > > not done, and if we implemented it, would be a hack (although > compromisable in this scheme, would be essentially a fake portageq > command)anrRokydtysyyetntgsI > > > * Portage must provide a way for external programs to obtain the > > base path for a repository with a given ID. It is assumed that this > > will be in the form of a ``portageq`` command (e.g. ``portageq > > get_repo_root gentoo-x86``). > > same as above > > > > > * Portage must extend ``portageq has_version`` to support > > restrictions to a given repository ID. > > and again > > > > > * Portage must extend ``portageq`` to implement a command which > > returns whether or not the profile used for a given repository ID > > is exactly the given profile (e.g. ``portageq profile_used > > default-linux/sparc/sparc64/2004.3 gentoo-x86``). > > and again > > > > > These extensions are assumed during the following specification. > > > > I have no problem with basically writing up 'fake' portageq calls. > However often people tell me overlays are important, they don't serve > as multipile repos and don't have metadata/news, so they are excluded > in this specification (intentially?). Portage doesn't do multiple > repo's so any repo-related call will be a 'fake' one, that just > returns the expected data, unless someone has a better method (looks > at other portage devs). I was assuming that given Portage's current lack of multiple repository support it would simply look to existing settings for all of these. The name can be grabbed from profiles/repo_name which already exists; the path can just return $PORTDIR if the name matches and error if not; the repository restrictions for has_version can simply be ignored, and the profile can check /etc/make.profile. > I am not sure if I pointed this out before, but I feel that news > items should be of a pragmatic nature. IE they should be useful but > not frequent. It should not be overly difficult to post a news item > for a particular incident. If news items are constantly being shot > down due to "importance" or some other reason that lacks what I would > call a reasonable blocking reason ( ie bad grammar, clarity problems, > inaccuracies ) it will discourage developers from submitting them. > While I am against completely crap news items, I would rather see > more news items than very few. While I don't like to appeal to common sense, given the ability to filter displaying of items based on profile, package installed, etc, it should be fairly easy to avoid flooding people with irrelevant news items without raising the bar so high that it discourages people. -- gentoo-dev@gentoo.org mailing list
