Gentoo Archives: gentoo-dev

From: Stuart Herbert <stuart@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Revisiting GLEP 19
Date: Wed, 21 Jul 2004 19:59:55
In Reply to: Re: [gentoo-dev] Revisiting GLEP 19 by
1 On Wednesday 21 July 2004 17:34, aeriksson@××××××××.fm wrote:
2 > > Two things. First off, I'd hope to achieve a lot more than just adding a
3 > > [S] entry to emerge -pv.
4 >
5 > Care to elaborate? "It's nifty for the future" is a bad argument. Far
6 > too many times have I came across people who thinks all problems goes
7 > away if the solution is implemented using xml (I'm NOT saying you're
8 > one of them). Present the problems you want to fix, and we'll discuss
9 > them.
11 Let's deal with the XML vs plain text argument first.
13 I'm not an XML-everywhere person, but I do believe that XML is *the* right
14 technology when you want to add meaning to structured data - meaning that can
15 be re-used in software tools. It's nowhere near as difficult to use as
16 ASN.1, not as clumbsy as the plain-text markups in common-use, and if you do
17 read the raw XML in a text editor, most people can follow what the file says.
19 You *can* do everything I'm suggesting below using a plain text file -
20 provided everyone follows the same conventions. You might even be successful
21 in getting everyone to keep to the conventions. But using XML for the job
22 gives your tool-writers instant access to rich libraries for parsing,
23 manipulating, and verifying the data. These libraries are available to
24 programmers in all the major languages (except bash alas ... perhaps it's
25 time for someone to change that? ;-) Tools that work on XML data are much
26 easier to write, and much easier to maintain.
28 Our changelogs are supposed to contain the following information:
30 - package version affected
31 - list of changed files
32 - reason for change
33 - bug(s) addressed by the change (inc security issues announced through GLSAs)
34 - developer who made the change
35 - user(s) who originally suggested the change (credit for patches, ebuilds,
36 and the like)
38 Let's look at what we could do with this sort of data.
40 Now, if I'm reading a changelog, if I want to see what issues are fixed, the
41 changelog isn't normally enough. Why? Because it's very common for the
42 changelog to only contain a bug number and not a description. Normally, you
43 have to open up a browser, and search for each bug in turn on
44 It's not exactly hard work, but we could make a better
45 experience.
47 There's no reason why the changelog couldn't contain both the bug id and the
48 summary line from bugzilla. There's no reason why a GUI tool like Porthole -
49 or even the command-line based emerge - couldn't provide you with a [more]
50 link to go and get the full discussion from bugzilla. Instead of unconnected
51 data stored in different places, we now have connected data and a means to
52 connect them. That idea - of making it possible for tools to connect the
53 data - of making it possible for the tools to understand the data - is where
54 the real value of XML lies.
56 If we were really wanting to take this further, for those packages that
57 provide a list of upstream bugs that are fixed in a release, we could store
58 that list in the changelogs too, with summaries and click-throughs. That's a
59 bit more work, and not everyone's idea of fun, but it could be done. At the
60 very least we could provide a link to the upstream changelog.
62 That's just looking at one aspect of bugs and changes. Being able to say
63 whether a bug fix is security-related or not is another aspect. That's just
64 another type of change information. It shouldn't have to be stored and
65 treated as a special case - which is where the glsa-check tool seems to be
66 going.
68 Let's look at the reasons why a new version of a package is added to Portage.
69 I believe 'version bump' will prove the most popular in our changelogs right
70 now. Is it to address serious bugs? Is it for security reasons? We could
71 standardise that into a choice of one or more reasons. That's information
72 that can then be used by GUIs such as Porthole and
73 That's information that users could search on.
75 Where is the upstream changelog? Something else that can be added. If you
76 write your tools correctly, you can introduce new types of information into
77 your XML data without having to change your tools.
79 I'm in the information business. I work on publishing tools for developers.
80 I work on a CMS tool (yes, it's XML based). I write about my work. I work
81 with information probably more than I work with code. Most information just
82 doesn't exist in isolation. Most information is really just information
83 about yet more information, information that people don't read because it
84 isn't served to them on a plate.
86 It's not about getting left behind. I didn't buy that argument during the
87 dotcom boom, and I definitely don't buy it now. What it's about is making a
88 lot more of what we already have, by making it more available. To make it
89 more available to people, you have to make it more available to the tools
90 first.
92 I'm not looking for problems to fix. "It ain't broke, so don't fix it" isn't
93 always the best advice. Sometimes, the thing to do is to look at what is
94 possible, rather than just accept what you're stuck with today.
96 Now, maybe this information should be part of the metadata for an ebuild
97 instead of being in a 'ChangeLog' - as Weeve was aluding to earlier in this
98 thread. From an SCM point of view, it's all configuration information
99 related to a change, whether you want to call it a 'ChangeLog' or
100 'metadata.xml' file or whatever.
102 > Why not add that bit of info the the ebuild which incorporates the
103 > fix? "SECURITYFIX=url1 url2"
104 > would be all need.
106 That's one way to do it. Build another special case into ebuilds and into
107 Portage. It'll work. But if the information was somewhere in XML, it'd be
108 an easier change to introduce. All you'd have to do would be to update an
109 XML schema. You shouldn't have to update tools.
111 > Or put the other way around, why not move
112 > all the other headers in ebuilds to xml, and use xml-aware tools to
113 > execute on them? (joke)
115 That's a topic that keeps cropping up. If you look at our GLEPs, there's one
116 currently open with people chomping at the bit to make that happen, at least
117 for some of the information.
119 Best regards,
120 Stu
121 --
122 Stuart Herbert stuart@g.o
123 Gentoo Developer
126 GnuPG key id# F9AFC57C available from
127 Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C
128 --


Subject Author
Re: [gentoo-dev] Revisiting GLEP 19 Marius Mauch <genone@g.o>