1 |
On Sat, 17 Dec 2005 21:50:47 -0800 Brian Harring <ferringb@g.o> |
2 |
wrote: |
3 |
| Drop the magic-chicken crap (especially in light of your comments |
4 |
| about 'professional' news inline in the glep). |
5 |
|
6 |
Eh, there aren't any magic chickens in the glep. |
7 |
|
8 |
| Not really. Just requires your code to be space safe. |
9 |
| |
10 |
| You write good code, right? Especially since you need to keep our |
11 |
| path handling safe for osx (/volumes) and for users who do strange |
12 |
| things? |
13 |
|
14 |
The problem isn't my code. My code's fine. So is eselect. The problem is |
15 |
people who write their own handler scripts to suit their own needs, and |
16 |
then get nastily bitten because they don't realise we're allowing |
17 |
spaces in filenames. |
18 |
|
19 |
Do you remember that Apple installer program that ended up in effect |
20 |
doing rm -fr / if you tried to install a particular OS X program to a |
21 |
volume whose name contained a space? |
22 |
|
23 |
| > * Portage must extend ``portageq`` to implement a command which |
24 |
| > returns whether or not the profile used for a given repository ID |
25 |
| > matches a certain base path (e.g. ``portageq profile_used |
26 |
| > default-linux/sparc/sparc64/2004.3 gentoo-x86``). |
27 |
| |
28 |
| profile_in_use, maybe. |
29 |
|
30 |
Mmm, that use looks too much like USE. *shrug* Exact names don't matter |
31 |
at this stage anyway. |
32 |
|
33 |
| > News items should be signed with a detached GPG signature: :: |
34 |
| |
35 |
| why should vs must? |
36 |
| Should leaves open the possibility for a tree compromise and a news |
37 |
| item with Very Bad(tm) instructions stuck into it. |
38 |
| |
39 |
| Moving towards getting the whole tree signed, introducing new |
40 |
| components that aren't required signed works against that. |
41 |
|
42 |
I don't want to introduce any signing requirements that we don't have |
43 |
already. When signing for everything else becomes mandatory, signing |
44 |
for news would be too. If I make this a 'must', someone will ask me to |
45 |
specify how we're handling the Gentoo keyring... |
46 |
|
47 |
| > ``Revision:`` |
48 |
| > Initially 1. Incremented every time a non-trivial change is |
49 |
| > made. Changes which require a re-read of the news item should |
50 |
| > instead use a new news item file. Mandatory. |
51 |
| |
52 |
| non-trivial changes that don't require a re-read sounds like a |
53 |
| contradiction. Clarify, especially since portage will mark this as |
54 |
| read _once_ and only once. |
55 |
|
56 |
Hrm, word it as "Changes other than minor formatting tweaks", or remove |
57 |
"non-trivial"? |
58 |
|
59 |
| > The following headers are used for filtering: |
60 |
| > |
61 |
| > ``Display-If-Installed:`` |
62 |
| > A dependency atom or simple package name (for example, |
63 |
| |
64 |
| Drop the 'simple package name'; it still is an atom. |
65 |
|
66 |
Ok. |
67 |
|
68 |
| This isn't incredibly useful if ranged versions are ever introduced. |
69 |
| Ammending the glep for that seems stupid, looser language might be |
70 |
| wise. |
71 |
|
72 |
What's the syntax for ranged versions? And how do they differ from SLOT |
73 |
versions? |
74 |
|
75 |
| |
76 |
| > .. Note:: When performing package moves, developers must also |
77 |
| > update any |
78 |
| > relevant ``Display-If-Installed`` headers in news files. |
79 |
| |
80 |
| Grounds for someone to get off their ass and do some work, but this |
81 |
| should be automated in some fashion- specifically detection of it |
82 |
| (auto-updating won't work with signing). |
83 |
|
84 |
Moving packages in general requires a re-sign anyway. I'm guessing that |
85 |
epkgmove will handle this, if it ever starts working again... |
86 |
|
87 |
| That's an implementation note, but I'm bringing it up since the time |
88 |
| to do the filter/cache instantiation is during portage initialization |
89 |
| (yes it sucks, but your stuck with stable)... so start thinking about |
90 |
| ways to make it fast, since python -c'import portage' is the slowest |
91 |
| part of portage queries |
92 |
|
93 |
Looks like I might have to do that thing in Python rather than bash |
94 |
then... |
95 |
|
96 |
| > News Item Quality Control |
97 |
| > ------------------------- |
98 |
| > |
99 |
| > There have been complaints regarding the comprehensibility of some |
100 |
| > upgrade notices and news items in the past. This is |
101 |
| > understandable ??? not every Gentoo |
102 |
| |
103 |
| '???' ? |
104 |
|
105 |
It's a dash. It'll show properly in the HTML version. |
106 |
|
107 |
| |
108 |
| > .. Note:: A previous draft of this GLEP allowed news items to be |
109 |
| > sent to ``gentoo-core`` instead of ``gentoo-dev``. It is possible |
110 |
| > that a situation may arise where this will be necessary (for |
111 |
| > example, a security update which must break backwards compatibility |
112 |
| > and which cannot be revealed to the public before a given date). |
113 |
| |
114 |
| Drop that and just state that -core doesn't fly sans security |
115 |
| consideration; referencing one of the previous 5 versions isn't |
116 |
| needed (yes it's minor, but it's uneeded info). |
117 |
|
118 |
Ok, the entire Note's gone. If we ever really have to do a nasty update |
119 |
for security reasons, whichever poor shmuck ends up handling it should |
120 |
be smart enough to know what to do... |
121 |
|
122 |
| We generate a tree every 30 minutes. You aiming for every update, or |
123 |
| for less frequent (once an hour fex)? |
124 |
| |
125 |
| Matters due to the fact rsync tree generation has a window it must |
126 |
| not overrun- minor but continuing the "lets be explicit" goal of |
127 |
| yours. |
128 |
|
129 |
Once an hour would work fine. On the other hand, the merge is just |
130 |
copying a few small files -- time-wise, it's less than generating the |
131 |
cache for a couple of ebuilds. |
132 |
|
133 |
| > The main rsync tree will **not** use the ``yyyy/mm/`` subdirectory |
134 |
| > layout. |
135 |
| |
136 |
| What shall it use? Again, be explicit. |
137 |
|
138 |
+ The news item directories will be moved into the single top level |
139 |
directory. |
140 |
|
141 |
Not sure whether we really want to do that. It makes the client code |
142 |
slightly easier... |
143 |
|
144 |
| -file named ``/var/lib/gentoo/news/news-repoid.unread`` (if it does |
145 |
| not +file named ``/var/lib/gentoo/news/news-${repoid}.unread`` (if it |
146 |
| does not |
147 |
| |
148 |
| Clearer at a first read though imo. |
149 |
|
150 |
Ok. |
151 |
|
152 |
| ask is superfluous, nuke it. |
153 |
|
154 |
Waah! I was told last time around that I had to add it. Looks like I |
155 |
might have to taint myself by trying emerge --ask to see what it really |
156 |
does... |
157 |
|
158 |
| You haven't stated how the 'package manager' will trigger the user's |
159 |
| reader of choice for these targets. Should also extend this to allow |
160 |
| a way to disable any news notices, lest someone's cronjob get hung |
161 |
| displaying news (feature or not, it's needed). |
162 |
|
163 |
The same way the package manager handles updating config files: it |
164 |
won't. It'll just tell the user that some news items need reading. |
165 |
|
166 |
|
167 |
| > The package manager must keep track of news items that have already |
168 |
| > been added to the unread list to avoid repeatedly marking a deleted |
169 |
| > news item. This could be handled via a ``news-repoid.skip`` file |
170 |
| > containing the IDs of news items that have already been added to a |
171 |
| > ``news-repoid.unread`` file, but this method is not required by |
172 |
| > this GLEP. |
173 |
| |
174 |
| Specifics. |
175 |
|
176 |
I'm trying to avoid forcing a particular implementation on the skip |
177 |
file, since I can think of at least three different ways of doing it |
178 |
and I'm not sure which will be fastest... |
179 |
|
180 |
| > When a news item is read, its name should be removed from the |
181 |
| > ``news-repoid.unread`` file. If a news client acts as an |
182 |
| > interactive reader rather than a gateway, it should then add the |
183 |
| > name to a ``news-repoid.read`` file in the same directory with the |
184 |
| > same file format. |
185 |
| |
186 |
| implementation issue; you need locking on this. If portage has to |
187 |
| farm out to the users reader of choice, then it needs to lock the |
188 |
| file to keep readers/writers from screwing with each other. |
189 |
|
190 |
We do? Marius told me it wasn't worth it. |
191 |
|
192 |
| Flock preferably, since it's faster then resorting to hardlink |
193 |
| trickery (yes this may be harder for shell crap, but so it goes since |
194 |
| hardlink locking sucks). |
195 |
|
196 |
What's wrong with mkdir? |
197 |
|
198 |
| > News items can be removed (by removing the news file from the main |
199 |
| > tree) when they are no longer relevant, if they are made obsolete |
200 |
| > by a future news item or after a long period of time. This is the |
201 |
| > same as the method used for ``updates`` entries. |
202 |
| |
203 |
| implementation issue; updating unread/skip crap so it doesn't bloat |
204 |
| is required, but time frame also matters (crap sync resulting in news |
205 |
| getting removed, yet it still being valid, just missing from the |
206 |
| local tree). |
207 |
|
208 |
Hrm. We can't take the same approach here as we do with expiring |
209 |
updates entries? |
210 |
|
211 |
| > There is an existing automated tool [#forums-glsa]_ for posting |
212 |
| > GLSAs to the forums. A similar tool can be used for these news |
213 |
| > items. |
214 |
| |
215 |
| Pawned it off on someone, or something you'll be doing? |
216 |
|
217 |
Hopefully the former. I have it on reasonably good authority that it |
218 |
won't take more than half an hour if I end up having to do it though... |
219 |
|
220 |
-- |
221 |
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) |
222 |
Mail : ciaranm at gentoo.org |
223 |
Web : http://dev.gentoo.org/~ciaranm |