Gentoo Archives: gentoo-dev

From: aeriksson@××××××××.fm
To: stuart@g.o
Cc: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Revisiting GLEP 19
Date: Wed, 21 Jul 2004 16:36:29
Message-Id: 20040721163435.7F10B3F03@latitude.mynet.no-ip.org
1 > On Wednesday 21 July 2004 16:25, aeriksson@××××××××.fm wrote:
2 > > I second that feeling. If what we're trying to achieve is to have a
3 > > way to signal to the sysadmins that a security update is present, why
4 > > not just add a [S] entry to 'emerge -pv'?
5 >
6 > Two things. First off, I'd hope to achieve a lot more than just adding a
7 > [S] entry to emerge -pv.
8
9 Care to elaborate? "It's nifty for the future" is a bad argument. Far
10 too many times have I came across people who thinks all problems goes
11 away if the solution is implemented using xml (I'm NOT saying you're
12 one of them). Present the problems you want to fix, and we'll discuss
13 them.
14
15
16 >> Secondly, where do you think Portage will get the information from
17 >> to decide whether or not to add the [S]? Right now, the design of
18 the
19 >> glsa toolset is to bolt this information onto the side. With
20 XML-based
21 >> changelogs, the information could be stored where it belongs - in
22 the
23 >> list of what has changed and why.
24
25
26 Why not add that bit of info the the ebuild which incorporates the
27 fix? "SECURITYFIX=url1 url2 http://www.gentoo.org/GLSA1234whatever"
28 would be all need.
29
30 For a sysadmin who's not into updating every day for the fun of it,
31 the stream of new ebuilds _with_ SECURITYFIX clauses would constitute
32 'vertual dependecies" he like to depend on. So from his pow, it's
33 legit ebuild information. Or put the other way around, why not move
34 all the other headers in ebuilds to xml, and use xml-aware tools to
35 execute on them? (joke)
36
37 BR,
38
39 /Anders
40
41
42
43 --
44 gentoo-dev@g.o mailing list

Replies

Subject Author
Re: [gentoo-dev] Revisiting GLEP 19 Stuart Herbert <stuart@g.o>