Gentoo Archives: gentoo-dev

From: "Tiziano Müller" <dev-zero@g.o>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: GLEP 46: Allow upstream tags in metadata.xml
Date: Sat, 19 Jan 2008 15:14:39
Message-Id: fmt444$87g$1@ger.gmane.org
In Reply to: Re: [gentoo-dev] GLEP 46: Allow upstream tags in metadata.xml by Alistair Bush
1 Alistair Bush wrote:
2
3 >
4 >
5 > Tiziano Müller wrote:
6 >> Current state: "Deferred"
7 >> Wanted state: "Accepted/Implemented" (at least by me)
8 >>
9 >> Open questions from last discussion (March 2006):
10 >> - Is it possible/should it be possible to have more than one <maintainer>
11 >> entry?
12 >
13 > Yes
14 >
15 >> - Is recording an upstream-status (active/inactive) a good idea?
16 > Maybe, leaning to No.
17 >
18 > What about packages that have multiple slots, e.g php-4, php-5? one
19 > slot could be inactive the other not, does that make upstream active?
20 Well, upstream for php-4 is not inactive (it still exists but answers with
21 a "won't fix" if you report a bug for php-4).
22
23 But there might be a case that there are two maintainers of different
24 branches of a software. Doesn't seem like a common case, does it?
25 Nevertheless: ideas?
26
27 >
28 >> Possibilities:
29 >> An element: <status>{active/inactive}</status>
30 >
31 > Status of what? seeing you have proposed a upstream-status and a
32 > maintainer status. what else is there left to status :P
33 There will be a <maintainer> tag within the <upstream></upstream>, not the
34 same as our already existing <maintainer>
35
36 But the question I tried to express (probably not clear enough) is:
37 Should (if at all) the status being tracked for <upstream> or for
38 <maintainer> (within upstream).
39
40 As an example "dev-libs/xmlwrapp": The original maintainer is inactive, but
41 there is a new one who took the package to sourceforge and it's not a fork
42 since the original maintainer agreed up on this. Should such a case be
43 tracked at all?
44
45 >
46 >> An attribute: <maintainer status="{active/inactive}">...
47 > No. As i'm pretty sure that every inactive maintainer won't go around
48 > updating their packages metadata.xml
49 Not talking about the existing <maintainer> tag, sorry.
50
51 >
52 >> - Is an additional <doc> element needed to link to upstream docs
53 > Interesting. what about the situation where upstream documentation sucks
54 > but there is a "better" resource provided by a third party, could we
55 > link to that? e.g. http://tldp.org for bash is an excellent resource
56 > Multiple doc links?
57 > <docs><official-doc/><official-doc/><doc/><doc/></docs> could provide
58 > that. Only concern I see is that this could relate to an endorsement of
59 > thirdparty websites, which may change negatively ( porn on tldp.org ) or
60 > my just become outdated.
61 >
62 > Actually without the multiple official/unofficial doc tags I would have
63 > to say No. as 99% of the time it would just be "${HOMEPAGE}/doc" or
64 > there would be a big fat link from the homepage and therefore would be
65 > of no real benefit.
66
67 Hmm, good point. Maybe we have to narrow the specification for <doc> to only
68 point to package maintainer info?
69 Since it can also change between versions, slots, etc...
70
71
72
73 --
74 gentoo-dev@l.g.o mailing list

Replies

Subject Author
Re: [gentoo-dev] Re: GLEP 46: Allow upstream tags in metadata.xml "Santiago M. Mola" <coldwind@g.o>