On Sat, 17 Dec 2005 21:50:47 -0800 Brian Harring <[EMAIL PROTECTED]> wrote: | Drop the magic-chicken crap (especially in light of your comments | about 'professional' news inline in the glep).
Eh, there aren't any magic chickens in the glep.
| Not really. Just requires your code to be space safe.
|
| You write good code, right? Especially since you need to keep our
| path handling safe for osx (/volumes) and for users who do strange
| things?
The problem isn't my code. My code's fine. So is eselect. The problem is
people who write their own handler scripts to suit their own needs, and
then get nastily bitten because they don't realise we're allowing
spaces in filenames.
Do you remember that Apple installer program that ended up in effect
doing rm -fr / if you tried to install a particular OS X program to a
volume whose name contained a space?
| > * Portage must extend ``portageq`` to implement a command which
| > returns whether or not the profile used for a given repository ID
| > matches a certain base path (e.g. ``portageq profile_used
| > default-linux/sparc/sparc64/2004.3 gentoo-x86``).
|
| profile_in_use, maybe.
Mmm, that use looks too much like USE. *shrug* Exact names don't matter
at this stage anyway.
| > News items should be signed with a detached GPG signature: ::
|
| why should vs must?
| Should leaves open the possibility for a tree compromise and a news
| item with Very Bad(tm) instructions stuck into it.
|
| Moving towards getting the whole tree signed, introducing new
| components that aren't required signed works against that.
I don't want to introduce any signing requirements that we don't have
already. When signing for everything else becomes mandatory, signing
for news would be too. If I make this a 'must', someone will ask me to
specify how we're handling the Gentoo keyring...
| > ``Revision:``
| > Initially 1. Incremented every time a non-trivial change is
| > made. Changes which require a re-read of the news item should
| > instead use a new news item file. Mandatory.
|
| non-trivial changes that don't require a re-read sounds like a
| contradiction. Clarify, especially since portage will mark this as
| read _once_ and only once.
Hrm, word it as "Changes other than minor formatting tweaks", or remove
"non-trivial"?
| > The following headers are used for filtering:
| >
| > ``Display-If-Installed:``
| > A dependency atom or simple package name (for example,
|
| Drop the 'simple package name'; it still is an atom.
Ok.
| This isn't incredibly useful if ranged versions are ever introduced.
| Ammending the glep for that seems stupid, looser language might be
| wise.
What's the syntax for ranged versions? And how do they differ from SLOT
versions?
|
| > .. Note:: When performing package moves, developers must also
| > update any
| > relevant ``Display-If-Installed`` headers in news files.
|
| Grounds for someone to get off their ass and do some work, but this
| should be automated in some fashion- specifically detection of it
| (auto-updating won't work with signing).
Moving packages in general requires a re-sign anyway. I'm guessing that
epkgmove will handle this, if it ever starts working again...
| That's an implementation note, but I'm bringing it up since the time
| to do the filter/cache instantiation is during portage initialization
| (yes it sucks, but your stuck with stable)... so start thinking about
| ways to make it fast, since python -c'import portage' is the slowest
| part of portage queries
Looks like I might have to do that thing in Python rather than bash
then...
| > News Item Quality Control
| > -------------------------
| >
| > There have been complaints regarding the comprehensibility of some
| > upgrade notices and news items in the past. This is
| > understandable ??? not every Gentoo
|
| '???' ?
It's a dash. It'll show properly in the HTML version.
|
| > .. Note:: A previous draft of this GLEP allowed news items to be
| > sent to ``gentoo-core`` instead of ``gentoo-dev``. It is possible
| > that a situation may arise where this will be necessary (for
| > example, a security update which must break backwards compatibility
| > and which cannot be revealed to the public before a given date).
|
| Drop that and just state that -core doesn't fly sans security
| consideration; referencing one of the previous 5 versions isn't
| needed (yes it's minor, but it's uneeded info).
Ok, the entire Note's gone. If we ever really have to do a nasty update
for security reasons, whichever poor shmuck ends up handling it should
be smart enough to know what to do...
| We generate a tree every 30 minutes. You aiming for every update, or
| for less frequent (once an hour fex)?
|
| Matters due to the fact rsync tree generation has a window it must
| not overrun- minor but continuing the "lets be explicit" goal of
| yours.
Once an hour would work fine. On the other hand, the merge is just
copying a few small files -- time-wise, it's less than generating the
cache for a couple of ebuilds.
| > The main rsync tree will **not** use the ``yyyy/mm/`` subdirectory
| > layout.
|
| What shall it use? Again, be explicit.
+ The news item directories will be moved into the single top level
directory.
Not sure whether we really want to do that. It makes the client code
slightly easier...
| -file named ``/var/lib/gentoo/news/news-repoid.unread`` (if it does
| not +file named ``/var/lib/gentoo/news/news-${repoid}.unread`` (if it
| does not
|
| Clearer at a first read though imo.
Ok.
| ask is superfluous, nuke it.
Waah! I was told last time around that I had to add it. Looks like I
might have to taint myself by trying emerge --ask to see what it really
does...
| You haven't stated how the 'package manager' will trigger the user's
| reader of choice for these targets. Should also extend this to allow
| a way to disable any news notices, lest someone's cronjob get hung
| displaying news (feature or not, it's needed).
The same way the package manager handles updating config files: it
won't. It'll just tell the user that some news items need reading.
| > The package manager must keep track of news items that have already
| > been added to the unread list to avoid repeatedly marking a deleted
| > news item. This could be handled via a ``news-repoid.skip`` file
| > containing the IDs of news items that have already been added to a
| > ``news-repoid.unread`` file, but this method is not required by
| > this GLEP.
|
| Specifics.
I'm trying to avoid forcing a particular implementation on the skip
file, since I can think of at least three different ways of doing it
and I'm not sure which will be fastest...
| > When a news item is read, its name should be removed from the
| > ``news-repoid.unread`` file. If a news client acts as an
| > interactive reader rather than a gateway, it should then add the
| > name to a ``news-repoid.read`` file in the same directory with the
| > same file format.
|
| implementation issue; you need locking on this. If portage has to
| farm out to the users reader of choice, then it needs to lock the
| file to keep readers/writers from screwing with each other.
We do? Marius told me it wasn't worth it.
| Flock preferably, since it's faster then resorting to hardlink
| trickery (yes this may be harder for shell crap, but so it goes since
| hardlink locking sucks).
What's wrong with mkdir?
| > News items can be removed (by removing the news file from the main
| > tree) when they are no longer relevant, if they are made obsolete
| > by a future news item or after a long period of time. This is the
| > same as the method used for ``updates`` entries.
|
| implementation issue; updating unread/skip crap so it doesn't bloat
| is required, but time frame also matters (crap sync resulting in news
| getting removed, yet it still being valid, just missing from the
| local tree).
Hrm. We can't take the same approach here as we do with expiring
updates entries?
| > There is an existing automated tool [#forums-glsa]_ for posting
| > GLSAs to the forums. A similar tool can be used for these news
| > items.
|
| Pawned it off on someone, or something you'll be doing?
Hopefully the former. I have it on reasonably good authority that it
won't take more than half an hour if I end up having to do it though...
--
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail : ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm
signature.asc
Description: PGP signature
