1 |
Hi, |
2 |
|
3 |
On 10/31/05, Dave Shanker <dshanker@×××××.com> wrote: |
4 |
> What about Portage auto generating a upgrade file |
5 |
> (/usr/portage/notices (like it does with it's cache) and then |
6 |
> providing a notice at the end of an emerge than lets the user know |
7 |
> it's there and how to read it. We could even provide a switch in |
8 |
> portage to read the file and display the notices (emerge |
9 |
> --readnotice). |
10 |
> |
11 |
|
12 |
Noted this thread on stu's weblog, and found it very interesting. Just |
13 |
jumping in midway, so I might have missed some stuff. I agree that there |
14 |
currently are too many channels where a user could look for information, |
15 |
changing one of these channel to be an authorative one, and start using |
16 |
it more often could be a good solution. |
17 |
|
18 |
However stu's --news proposals looks interesting too, implementation |
19 |
wise maybe it's a good idea to look at the GLSA and GLEP type messages. |
20 |
They provide an excellent fixed, parsable format for changes already. And |
21 |
afaik are the defacto source for security and enhancement proposals. |
22 |
Maybe this should be extended to something like a GLCM (Gentoo Linux |
23 |
Change Message, be creative). if the format is XML defined, i'm sure |
24 |
the portage people can integrate it into emerge --pretend with a special |
25 |
flag, esp. if GLSA is already working. It's also easy to distribute these to |
26 |
websites, mailinglists, RSS etc. As a sideeffect it's also easier to talk about |
27 |
changes (compare, "GLCM 32", to "That apache change earlier this year"). |
28 |
One of the downsides of this could be that it places more work pressure on |
29 |
developers, but i'm sure a good generation tool will help with this. |
30 |
|
31 |
As a sidenote, The FreeBSD /usr/ports/UPGRADING is boring, but it works for |
32 |
me. |
33 |
|
34 |
Regards, |
35 |
|
36 |
Frido |
37 |
|
38 |
-- |
39 |
gentoo-dev@g.o mailing list |