From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.50) id 1EYS9v-0001oN-Dc for garchives@archives.gentoo.org; Sat, 05 Nov 2005 17:48:56 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jA5HleqW030927; Sat, 5 Nov 2005 17:47:40 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id jA5Hjg1o008972 for ; Sat, 5 Nov 2005 17:45:43 GMT Received: from 82-41-57-20.cable.ubr08.edin.blueyonder.co.uk ([82.41.57.20] helo=snowdrop.home) by smtp.gentoo.org with esmtpa (Exim 4.43) id 1EYS6o-0005z5-7V for gentoo-dev@lists.gentoo.org; Sat, 05 Nov 2005 17:45:42 +0000 Received: from localhost.home ([127.0.0.1] helo=snowdrop.home) by snowdrop.home with esmtp (Exim 4.54) id 1EYS6j-0008Ne-L6 for gentoo-dev@lists.gentoo.org; Sat, 05 Nov 2005 17:45:37 +0000 Date: Sat, 5 Nov 2005 17:45:35 +0000 From: Ciaran McCreesh To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two Message-ID: <20051105174535.52f6187d@snowdrop.home> In-Reply-To: <20051105112451.GA24767@nightcrawler> References: <20051105005814.0de0d8ff@snowdrop.home> <20051105112451.GA24767@nightcrawler> X-Mailer: Sylpheed-Claws 1.9.99-rc2 (GTK+ 2.6.10; i686-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary=Signature_Sat__5_Nov_2005_17_45_35_+0000_vl4JANLoXet9zg8o; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Archives-Salt: 7f3fdabf-df07-494b-9674-b430366d7309 X-Archives-Hash: 8e1872ff2e859b9f800d5be036ffb476 --Signature_Sat__5_Nov_2005_17_45_35_+0000_vl4JANLoXet9zg8o Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sat, 5 Nov 2005 05:24:51 -0600 Brian Harring wrote: | Drop the lightweight bit and merge it into multiple delivery. You're=20 | after lightweight _default_, which is fine, but the phrasing is a bit=20 | screwed. Hrm, I don't see those as contradictory. There's a requirement that the solution does not require anything fancy, and a requirement that the solution does not force one particular reading method upon the user. There's no requirement that the solution must not be usable with anything which is not lightweight. | > News items are published and delivered to users as follows: | | > 6. Portage filters the news item and, if it is relevant, installs | > it in a special location to be read by a news item reader. Messages | > are also displayed to inform the user that news is available. |=20 | Out of curiousity, how are you planning on having 101 general notices=20 | reigned down on a users head during an initial install? Yes, you | have the atom filter, but what about general notices? People who've just done an initial install won't have lots of packages installed. As for general notices, if there're lots of them we have serious issues... | Further, how are notices going to apply to users who don't have the=20 | package installed, then go and merge it? Your statement above | implies the irrevalent (at the time of sync) notices are ignored, | which breaks down under the scenario where a news item is pushed out | that apache configuration is going to change, I merge old style | apache after sync'ing the news, portage (due to your news id cache) | considers it deleted, and doesn't display it. Wording perhaps could be clearer... News items are added to the "don't copy again" list when they're copied, not when they're checked. | > News items may be signed using GPG. If this is done, a detached | > signature should be used. |=20 | I'd argue for must be, personally. A bogus news item claiming to be=20 | from portage devs, telling users to change their SYNC setting could=20 | cause massive mayhem. Signing elsewhere isn't mandatory yet. | Still haven't address my point about | A) package moves combined with news entries Gotta handle those manually / with epkgmove. Someone could write a server-side handler for automatic updates if they want, but given that package moves are already a case of "do all the things on a big list", it's not much added complexity... | B) N packages |=20 | Assume you mean that the bit above is a full DepSet, not a single | atom (if that's the case, clarify that N atoms are allowed). A single atom is probably sanest... | Should clarify USE conditionals are a no go- might be worth=20 | considering the full atom syntax (despite the fact portage doesn't=20 | currently support it for depends), use flags, slot, etc. I'd rather not try to guess what Portage may or may not support in the future. There's nothing precluding using :slot and [use] atoms if portage ever supports them. | > ``Display-If-Keyword:`` | > A keyword [#glep-22]_ name, for example ``mips``. If the user | > is on the arch in question, the news item should be displayed. |=20 | N keywords =3D=3D N Header entries? Yup. | No go on -core imo; it's a community/dev issue, should be visible to=20 | the general public rather then hidden away in the ml we do our | flaming in. There *might* be legit security reasons for using -core, for example for nasty "upgrade required" security bugs that we can't disclose before a given date. Hopefully this will never happen. | Already pointed out that this won't fly looking forward, it | implicitly assumes a single repository. Again, we can deal with that if Portage ever gets multiple repo support. Until it does, I'm not trying to guess how it's going to end up being implemented. | Nuke flashy (any phrasing that allows for blinking crap sliding into | portage I instinctively dislike). Is there a technical name for the big red !!!!! messages? | > Portage must keep track of news items which have already been | > installed to avoid repeatedly reinstalling a deleted news item. |=20 | Track it how, via the directory, or a secondary list? The GLEP doesn't require any particular implementation. | > 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. |=20 | Might want to consider a maximum period of time for news entries to=20 | linger by default; perhaps a header for controlling deletion (this is=20 | would require commit access for whatever does the scans obviously). We don't do this with updates or ebuilds or anything else, so I don't really see the point. | Stop using trivial (no it's not in reference to above, just hit the=20 | right word count where I'm whinging about it). But it's such a nice word! | Points above regarding working sanely for N repos need be addressed,=20 Which I'll do right before Portage gets N repo support. | So... reiterating jasons question, example where news items transcend=20 | package specific? Easy example? There might be changes in vim7 which would warrant a news item covering vim, gvim, vim-core, kvim. --=20 Ciaran McCreesh : Gentoo Developer (Anti-XML, anti-newbie conspiracy) Mail : ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm --Signature_Sat__5_Nov_2005_17_45_35_+0000_vl4JANLoXet9zg8o Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDbO/B96zL6DUtXhERAh61AKDH812/JxCEdRCAP7jpHOJaO83nvwCfcLqC 2SnHEYFls6u78nf2DkHpB48= =X5L5 -----END PGP SIGNATURE----- --Signature_Sat__5_Nov_2005_17_45_35_+0000_vl4JANLoXet9zg8o-- -- gentoo-dev@gentoo.org mailing list