Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Wed, Dec 14, 2005 at 09:54:06PM +, Ciaran McCreesh wrote: On Wed, 14 Dec 2005 13:48:45 -0800 Zac Medico [EMAIL PROTECTED] wrote: | I wish you'd reconsider, because I was looking forward to multiple | repository support. Well, if Portage ever gets multiple repository support, then news clients can be updated to handle it. The GLEP says that already. Care to clarify how that transition is going to occur? Your proposal, if you know a roadblock is coming down the line I expect it to be documented in the glep (with potential suggestions how to minimize the horkage). If you're not going to do N repo, state so in the glep, state that it _will_ break down the line, and that the issue while known, are being ignored despite portage developers concerns. Only fair the council knows the exact details, that and it made clear that this was known when proposed and ignored. If you're going to create and dump a mess on us, I expect it to be in the proposal- especially since your proposal is intrinsically portage bound. Thing that's daft out of all of this time wasting is that what's being asked of you is a couple of portageq calls so that we're not screwed over by a feature. Something along the lines of... portageq get_repo_id path # helper method of getting repo_id for a path (dar) portageq match root atom [repo-id] # method of limiting matching of vdb to a specific source repo portageq newsdir repo_id # get the absolute news path for said id. Integration for that is pretty damn simple from our side of things, and you get the major blocker of your news glep resolved (meaning it has a chance of actually passing). If it's too slow, I'd suggest since it's your proposal, looking for a method to batch up the calls (modularization of portageq would be required, which is available in the dead ebd branch already). Tricks of that sort are easily implemented, and don't require specs and gleps (just requires someone to do a minor bit of work). ~harring pgpQEwhHt8ZlE.pgp Description: PGP signature
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Sun, Dec 18, 2005 at 01:07:27AM +, Ciaran McCreesh wrote: On Sat, 17 Dec 2005 16:51:05 -0800 Brian Harring [EMAIL PROTECTED] wrote: | Transitioning from single news.unread to N is going to break clients | that expect a single. Yup. | As I said, you're going to break stuff- and you're building it into | your glep out of (aparent) stubborness. No no. I'm just not adding something ill defined and arbitrary to the GLEP to avoid introducing minor possible breakage when some ill defined and arbitrary change is made to Portage. Well, since we're toeing the line, I'll just state your glep is ill defined and arbitrary, it is inflexible and incomplete due to the fact it doesn't take into consideration the existing solutions (namely overlays). Back off the technical double speak insults unless you want others people to get nastier then they are already. | What do you want, another glep amending yours with that one little | detail? Probably won't be necessary... If you're unwilling to make your 'flexible' proposal actually flexible for anything but your stuff (eselect), either the glep is going to be fought tooth and nail or a competing glep is going to come out of this. Bluntly, stop being a tool, users want this feature, stop using it as fodder to fight. | The news glep crosses several groups, collaboration here is required, | meaning *listen* to the folk you're trying to command. Otherwise the | glep *will* go nowhere no matter how much noise you make. And I'm asking you to provide me with a specification of how multiple repositories will work. Without that, there's no way the GLEP can be made to handle multiple repositories. We have overlays already. That *is* multiple repositories. Stop trying to dodge the request by making us waste our time and produce a stand alone repository glep- overlays exist *now*, thus you *do* need to address them *now* else your glep is incomplete. | | If you're going to create and dump a mess on us, I expect it to | | be in the proposal- especially since your proposal is | | intrinsically portage bound. | | There's very little that's Portage bound. As originally requested, | I've tried to keep as much as is reasonably possible *out* of | Portage... | | It's distributed via the portage tree, it's updated by portage, the | check for new news items is *via* portage, and check for news items | prior to merging is done by portage. | | If that truly was your intention, you failed in it.. It's bound to | portage, despite the rhetoric. No no. A Portage bound solution would stick all the code and clients in Portage proper, rather than using Portage merely for hooks as far as is reasonably possible. Word games... You're dodging my point. | Word games suck, instead of playing them you *should* be trying to | address the concerns- iow, what do you *explicitly* need from | portage, What explicitly I need, *if* the GLEP is to specify multiple repository support from the outset, is a specification of how Portage will handle multiple repositories conceptually and a description of the interface that will be provided by Portage. Overlays. The only thing you need is a repo id, the only thing we need is to know what you'll be accessing, what we need to future proof from an api standpoint. | Especially since you've said we're not doing it the way you think | it should work... | | Where have I stated that? My statements thus far about multi repo | were in reference to a glep that missed the target. | | Provide quotes please, or get back to nailing down exactly what you | need portageq wise so we can state do it this way, and we'll shut | up. I'm thinking mainly about Portage externally will use user defined in relation to repository identification. Any specification on multiple repositories that comes from me will have said identifiers being repository designed, simply because I can't see a sane way of handling it otherwise. We've had this discussion once already, but I'll keep hammering the point till you follow it- external repo label is just that, what the user would specify on commandline. emerge --repo blah --rsync (fex). Internal ids are a seperate beast, and a simple solution *now* is that any repo that provides new must bundle an ID. Do that, and portage can made to use it for your news crap. Aliasing (user naming) is something *we* would add as a feature down the line. Why am I stating it as such? Because again, overlays exist now, and your glep is willfully leaving them out in the cold. | You want us to nail everything down for our request, I'd like you to | do the same (especially since we're stuck maintaining whatever you | propose/create). I can't nail down details on multiple repository support until I'm told what Portage will do. Give me a specification for what Portage will do and I'll quite happily make the GLEP work with it.
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Wednesday 14 December 2005 09:52, Ciaran McCreesh wrote: On Wed, 14 Dec 2005 09:11:51 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | newsdir=$(portageq envvar PORTDIR)/metadata/news | newsdir=$(portageq newsdir gentoo) | | Both have one level of indirection. The first has two hard coded | elements. The first has one. Where is the massive over-indirection? | | The second allows future changes. The first does not. Where does the | specification come into it? All that would be needed is to allow a | user a method to name overlays and it'd be useful straight off the | bat. The former relies upon existing, widely used functionality together with a well-defined path. The latter has some magic hard-coded name voodoo (what's a 'gentoo'?) and is still stuck only supporting a single location. What's a 'PORTDIR'? What's a 'metadata'? Outside of portage, these are also magic name voodoo. But I've grown tired of your imperfect circles. I think your design sucks and you think that my solution to making it not suck is too soon. The solution to that seems simple to me. Rather than have 'package manager' do anything, just have it provide hooks that will allow you to do your thing at the times you want. Good luck with solving the news in overlays bug when it comes in. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Wed, 14 Dec 2005 21:09:02 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | What's a 'PORTDIR'? A PORTDIR is a well defined, widely used variable. | What's a 'metadata'? A metadata is a well defined, widely used directory in the tree. | Outside of portage, these are also magic name voodoo. Sure. Where in the GLEP does it say that I care about supporting Debian? | But I've grown tired of your imperfect circles. I think your design | sucks and you think that my solution to making it not suck is too | soon. The solution to that seems simple to me. Rather than have | 'package manager' do anything, just have it provide hooks that will | allow you to do your thing at the times you want. Exactly what I am doing. Hence why I'm not making Portage know any more than it really really has to about news. -- 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
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
Ciaran McCreesh wrote: | soon. The solution to that seems simple to me. Rather than have | 'package manager' do anything, just have it provide hooks that will | allow you to do your thing at the times you want. Exactly what I am doing. Hence why I'm not making Portage know any more than it really really has to about news. I wish you'd reconsider, because I was looking forward to multiple repository support. You may want to specify the newsdir=$(portageq envvar PORTDIR)/metadata/news bit in the glep and also note in the glep that there were dissenting opinions regarding the assumptions that you have made there. Zac -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Wed, 14 Dec 2005 13:48:45 -0800 Zac Medico [EMAIL PROTECTED] wrote: | I wish you'd reconsider, because I was looking forward to multiple | repository support. Well, if Portage ever gets multiple repository support, then news clients can be updated to handle it. The GLEP says that already. -- 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
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Tuesday 13 December 2005 11:45, Andrew Muraco wrote: Jason Stubbs wrote: On Tuesday 13 December 2005 11:22, Ciaran McCreesh wrote: On Tue, 13 Dec 2005 11:17:30 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | So what are you going to do? I asked already but you didn't answer. | How are you going to find $PORTDIR/metadata/news? At present, by using portageq with a hardcoded suffix. If in the future Portage introduces new functionality, then clients and the specification can easily be updated to handle said functionality. And how can that be adapted to work with overlays, completely ignoring the possibility of distinct repositories. Overlays is something that exists already and news support for them is a request that will appear as soon as news support is added. Your Point is Moot ... Interesting use of capitals. because an overlay (at present) is going to be exprimental software, or a repository from a non-English speaking community Gentoo site... (unsupported offically anyways) and so you _should_ know what risks your taking, except if your a new non-English-speaking user utilizing such a repository. this GLEP is to warn you about supported updates/changes which you _need_ to know about. This GLEP is about getting news regarding a set of ebuilds to the user. Making it only about the Gentoo supported tree serves no purpose. Why should an overlay need to have news if the user has the consciensely update and maintain it to begin it. Because they already support package.mask, thirdpartymirrors, eclasses and just about anything else that exists in the supported tree. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Tuesday 13 December 2005 11:48, Ciaran McCreesh wrote: On Tue, 13 Dec 2005 11:39:14 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | And how can that be adapted to work with overlays, completely | ignoring the possibility of distinct repositories. Overlays is | something that exists already and news support for them is a request | that will appear as soon as news support is added. Overlays don't contain metadata directories There's nothing preventing this. and don't get synced, As Zac pointed out, esync exists. so they don't contain news items. Neither of the points above prevent an overlay from containing news items. Supporting news from multiple sources is something that's tied to supporting packages from multiple sources, which overlay doesn't permit. Overlays are used for getting packages from multiple sources every day. The only thing preventing them from supporting getting news from multiple sources is your stubborness against adding a single level of indirection - a level of indirection that has absolutely no cost to readers. Fixing that would require fixing portage to support multiple repositories rather than using overlay, which is an issue for a different GLEP. I'll say it again. It wouldn't require a GLEP because the changes wouldn't go beyond portage. At least they wouldn't if you'd allow portage to keep its internals internal. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
Jason Stubbs wrote: [Mon Dec 12 2005, 07:51:51PM CST] | There doesn't need to be a debate. This whole proposal doesn't care | about portage compatibility whatsoever and it's exactly this style of | thinking that slows down portage development (which everybody loves | to complain about so much). Sure it does. It cares about the way Portage is currently, and it cares about any reasonable future Portage changes. Bullshit. I'm not quite sure I understand the strong response. The GLEP was clearly designed to have a minimal impact on portage. Now I'm willing to listen to arguments that it does not, in fact, do that, but certainly the well-defined, minimal coupling between the news and emerge was not accidental. (Incidentally, I've never complained about the pace of portage development. I'm not developing it, so I don't complain about those who are.) Just as an aside, it would be nice if we could keep [EMAIL PROTECTED] vulgarity-free, since it's a list that's often read at work by a good number of people. | As I said already, there will immediately be a bug asking for overlay | support. Portage already supports multiple in a form whether anybody | likes it or not. How they are supported and how they will change | should be of no concern to the glep. What should be of concern is | establishing a robust API between the readers and portage such that | future changes won't cause breakage. Wouldn't it suffice for the GLEP to simply have a statement that it will query portage for a list of repositories, once there's a way to do that, but until then the default repo will be assumed? -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgp9qHX6VO2Cp.pgp Description: PGP signature
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Wednesday 14 December 2005 07:12, Grant Goodyear wrote: Jason Stubbs wrote: [Mon Dec 12 2005, 07:51:51PM CST] | As I said already, there will immediately be a bug asking for overlay | support. Portage already supports multiple in a form whether anybody | likes it or not. How they are supported and how they will change | should be of no concern to the glep. What should be of concern is | establishing a robust API between the readers and portage such that | future changes won't cause breakage. Wouldn't it suffice for the GLEP to simply have a statement that it will query portage for a list of repositories, once there's a way to do that, but until then the default repo will be assumed? Modifications are required to portage anyway. Why postpone it until after several readers are written and force all of them become broken? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Wed, 14 Dec 2005 08:44:39 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | Modifications are required to portage anyway. Why postpone it until | after several readers are written and force all of them become broken? Because there isn't a specification saying what the future changes to Portage will be, so supporting said future changes straight off would require a massively over-generalised, over-indirected solution. -- 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
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
Jason Stubbs wrote: [Tue Dec 13 2005, 05:44:39PM CST] Wouldn't it suffice for the GLEP to simply have a statement that it will query portage for a list of repositories, once there's a way to do that, but until then the default repo will be assumed? Modifications are required to portage anyway. Why postpone it until after several readers are written and force all of them become broken? Okay, so what is the portage team proposing to use for a repo query API? -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpKJpt3hG1A8.pgp Description: PGP signature
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Wednesday 14 December 2005 08:54, Ciaran McCreesh wrote: On Wed, 14 Dec 2005 08:44:39 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | Modifications are required to portage anyway. Why postpone it until | after several readers are written and force all of them become broken? Because there isn't a specification saying what the future changes to Portage will be, so supporting said future changes straight off would require a massively over-generalised, over-indirected solution. newsdir=$(portageq envvar PORTDIR)/metadata/news newsdir=$(portageq newsdir gentoo) Both have one level of indirection. The first has two hard coded elements. The first has one. Where is the massive over-indirection? The second allows future changes. The first does not. Where does the specification come into it? All that would be needed is to allow a user a method to name overlays and it'd be useful straight off the bat. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Wed, 14 Dec 2005 09:11:51 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | newsdir=$(portageq envvar PORTDIR)/metadata/news | newsdir=$(portageq newsdir gentoo) | | Both have one level of indirection. The first has two hard coded | elements. The first has one. Where is the massive over-indirection? | | The second allows future changes. The first does not. Where does the | specification come into it? All that would be needed is to allow a | user a method to name overlays and it'd be useful straight off the | bat. The former relies upon existing, widely used functionality together with a well-defined path. The latter has some magic hard-coded name voodoo (what's a 'gentoo'?) and is still stuck only supporting a single location. -- 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
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
For reference, I'm quoting this snippet from earlier in the thread: Jason Stubbs wrote: On Sunday 11 December 2005 10:35, Ciaran McCreesh wrote: .. Note:: Future changes to Portage involving support for multiple repositories may require one news list per repository. Assuming repositories have some kind of unique identifier, this file could be named ``news-repoid.unread``. Repositories will definitely have a unique identifier. Perhaps it would be better to use the repository-identifing format from the beginning so that readers are forced to be forwards-compatible? Assuming the readers would then output the repository name, labeling it gentoo should work well... [...] Ciaran McCreesh wrote: On Wed, 14 Dec 2005 09:11:51 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | newsdir=$(portageq envvar PORTDIR)/metadata/news | newsdir=$(portageq newsdir gentoo) | | Both have one level of indirection. The first has two hard coded | elements. The first has one. Where is the massive over-indirection? | | The second allows future changes. The first does not. Where does the | specification come into it? All that would be needed is to allow a | user a method to name overlays and it'd be useful straight off the | bat. The former relies upon existing, widely used functionality together with a well-defined path. The latter has some magic hard-coded name voodoo (what's a 'gentoo'?) and is still stuck only supporting a single location. Apparently, 'gentoo' is meant to be the identifier for the official gentoo repository (portage tree). It corresponds to 'magic-chicken' below. Ciaran McCreesh wrote: Whenever relevant unread news items are found, the package manager will create a file named ``/var/lib/gentoo/news/news-magic-chicken.unread`` (if it does not already exist) and append the news item identifier (eg ``2005-11-01-yoursql-updates``) on a new line. Zac -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
Ciaran McCreesh posted [EMAIL PROTECTED], excerpted below, on Sun, 11 Dec 2005 21:19:08 +: Does anyone really use emerge --ask? Oh, /my/ yes! The following should speak for itself. (I have a similar set of ep* commands, those in /usr/local/bin, so I can --pretend as my normal user. Yes, I do have autocompletion setup for them all, too, tho it was basically a matter of ensuring the gentoo autocompletion ran first, then using the same autocomplete functions emerge did, since these are almost all just special cases of the emerge command.) ~#cd /usr/local/sbin /usr/local/sbin#for eascript in ea* ;do echo $eascript;cat $eascript;done ea #!/bin/bash exec emerge -av --oneshot $* ea2 #!/bin/bash exec emerge -av $* eafetch #!/bin/bash exec emerge -avuDf $* eafetchworld #!/bin/bash exec emerge -avuDf world eapaK #!/bin/bash exec emerge -avk --oneshot $* eapaK2 #!/bin/bash exec emerge -avk $* eapak #!/bin/bash exec emerge -avK --oneshot $* eapak2 #!/bin/bash exec emerge -avK $* easync #!/bin/bash emerge sync eupdatedb emerge -avuDf world eatree #!/bin/bash exec emerge -avuDt --oneshot $* eatree2 #!/bin/bash exec emerge -avuDt $* eatreeworld #!/bin/bash exec emerge -avuDt world eaworld #!/bin/bash exec emerge -avuD world -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
Jason Stubbs posted [EMAIL PROTECTED], excerpted below, on Mon, 12 Dec 2005 09:11:53 +0900: On Monday 12 December 2005 09:01, Ciaran McCreesh wrote: On Mon, 12 Dec 2005 08:44:00 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | Repositories will be user-labelled. However, all that readers need be | concerned with is how to extract the repository name from the | news.unread file and how to then resolve that to a directory name, | regardless of how repositories are implemented. See, this is exactly why I'm not wanting to care about multiple repo details at this point. There's no specification of how they work and what exactly they're supposed to do, and to make matters worse the way you seem to think they'll be handled is a really really bad way of doing it. Regardless of what you think about the current plans for multiple repository support, the details that readers will need to know wont change. Ciaran hasn't stated, but it appears to me if I'm reading correctly between the lines, the reason he doesn't want to mess with specifying multiple repo details right now is that it's getting the cart before the horse in terms of nailing down certain areas of the multiple repo spec. For example, if repository-id forms a part of the path and we define path parsing now, then we are effectively defining legal characters for repository-id now. That's an entirely different glep, far out of scope and reaching into other people's territory, limiting how that might be implemented by defining a portion of the id-scope in an entirely unrelated glep. Given how heated I've seen GLEP discussion get (and I'm not saying that's /bad/, just a fact), I really can't blame Ciaran for attempting to keep the scope of the proposal, and therefore the debate, down to exactly what he's aiming to accomplish, without ending up getting into an entirely /different/ debate about how he's limiting the future flexibility of the multiple repo implementation. Once there's a concrete proposal there to work with, then and only then, he's saying (from my viewpoint), is it appropriate for consideration in relation to the news proposal. Don't unnecessarily tie the two together, complicating life for both. Let each be argued on its merits separately, and when/if multiple repo is actually close enough to deployment that there's some actual rules to work with, /then/ worry about fixing this to match. If I'm incorrect, just tell me to go back in my corner and lurk some more g, but that's what I'm getting out of this subthread so far. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Mon, 12 Dec 2005 23:49:31 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | No need for a glep as far as portage support goes anymore than Ciaran | needs a glep to change or add syntax highlighting in vim. The difference is, Vim syntax scripts are well established, and there aren't any design issues to solve. Multiple repository support clearly *isn't* obvious, because the solution you've described is the wrong one. | There doesn't need to be a debate. This whole proposal doesn't care | about portage compatibility whatsoever and it's exactly this style of | thinking that slows down portage development (which everybody loves | to complain about so much). Sure it does. It cares about the way Portage is currently, and it cares about any reasonable future Portage changes. | As I said already, there will immediately be a bug asking for overlay | support. Portage already supports multiple in a form whether anybody | likes it or not. How they are supported and how they will change | should be of no concern to the glep. What should be of concern is | establishing a robust API between the readers and portage such that | future changes won't cause breakage. Ok, give me a list of every single future enhancement to Portage and I'll make sure the GLEP will be compatible with them. -- 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
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Tuesday 13 December 2005 02:16, Ciaran McCreesh wrote: On Mon, 12 Dec 2005 23:49:31 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | No need for a glep as far as portage support goes anymore than Ciaran | needs a glep to change or add syntax highlighting in vim. The difference is, Vim syntax scripts are well established, and there aren't any design issues to solve. Multiple repository support clearly *isn't* obvious, because the solution you've described is the wrong one. Blah, blah, blah. | There doesn't need to be a debate. This whole proposal doesn't care | about portage compatibility whatsoever and it's exactly this style of | thinking that slows down portage development (which everybody loves | to complain about so much). Sure it does. It cares about the way Portage is currently, and it cares about any reasonable future Portage changes. Bullshit. | As I said already, there will immediately be a bug asking for overlay | support. Portage already supports multiple in a form whether anybody | likes it or not. How they are supported and how they will change | should be of no concern to the glep. What should be of concern is | establishing a robust API between the readers and portage such that | future changes won't cause breakage. Ok, give me a list of every single future enhancement to Portage and I'll make sure the GLEP will be compatible with them. Without a list of future features, you think the best way to go must be the least agile? As Zac said, all that matters to keep full compatibility on the side of the readers is to add a level of indirection. All your reasoning above falls apart in the face of that simple *logical* request. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Tue, 13 Dec 2005 10:51:51 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | Without a list of future features, you think the best way to go must | be the least agile? As Zac said, all that matters to keep full | compatibility on the side of the readers is to add a level of | indirection. All your reasoning above falls apart in the face of that | simple *logical* request. Every problem can be solved by adding another layer of indirection, except for the problem of having too many layers of indirection. This layer you are proposing is not going to do anything useful. It's merely adding indirection for the sake of it. There's no more need for this than there is need for a two thousand line XML DTD which allows us to specify the author's date of birth using an ancient Sumerian calendar. Come up with a full specification of how Portage will handle multiple repositories, and get that specification agreed upon by the people who will end up having to use it. *Then* come back and ask me to add in more complexity. I'm not going to over-complicate things to deal with random hypothetical half-baked speculation. -- 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
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Tuesday 13 December 2005 11:11, Ciaran McCreesh wrote: On Tue, 13 Dec 2005 10:51:51 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | Without a list of future features, you think the best way to go must | be the least agile? As Zac said, all that matters to keep full | compatibility on the side of the readers is to add a level of | indirection. All your reasoning above falls apart in the face of that | simple *logical* request. Every problem can be solved by adding another layer of indirection, except for the problem of having too many layers of indirection. This layer you are proposing is not going to do anything useful. It's merely adding indirection for the sake of it. There's no more need for this than there is need for a two thousand line XML DTD which allows us to specify the author's date of birth using an ancient Sumerian calendar. Come up with a full specification of how Portage will handle multiple repositories, and get that specification agreed upon by the people who will end up having to use it. *Then* come back and ask me to add in more complexity. I'm not going to over-complicate things to deal with random hypothetical half-baked speculation. So what are you going to do? I asked already but you didn't answer. How are you going to find $PORTDIR/metadata/news? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Tue, 13 Dec 2005 11:17:30 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | So what are you going to do? I asked already but you didn't answer. | How are you going to find $PORTDIR/metadata/news? At present, by using portageq with a hardcoded suffix. If in the future Portage introduces new functionality, then clients and the specification can easily be updated to handle said functionality. -- 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
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Tuesday 13 December 2005 11:22, Ciaran McCreesh wrote: On Tue, 13 Dec 2005 11:17:30 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | So what are you going to do? I asked already but you didn't answer. | How are you going to find $PORTDIR/metadata/news? At present, by using portageq with a hardcoded suffix. If in the future Portage introduces new functionality, then clients and the specification can easily be updated to handle said functionality. And how can that be adapted to work with overlays, completely ignoring the possibility of distinct repositories. Overlays is something that exists already and news support for them is a request that will appear as soon as news support is added. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
Jason Stubbs wrote: On Tuesday 13 December 2005 11:22, Ciaran McCreesh wrote: On Tue, 13 Dec 2005 11:17:30 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | So what are you going to do? I asked already but you didn't answer. | How are you going to find $PORTDIR/metadata/news? At present, by using portageq with a hardcoded suffix. If in the future Portage introduces new functionality, then clients and the specification can easily be updated to handle said functionality. And how can that be adapted to work with overlays, completely ignoring the possibility of distinct repositories. Overlays is something that exists already and news support for them is a request that will appear as soon as news support is added. -- Jason Stubbs Your Point is Moot because an overlay (at present) is going to be exprimental software, (unsupported offically anyways) and so you _should_ know what risks your taking, this GLEP is to warn you about supported updates/changes which you _need_ to know about. Why should an overlay need to have news if the user has the consciensely update and maintain it to begin it. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
Ciaran McCreesh wrote: On Tue, 13 Dec 2005 11:39:14 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | And how can that be adapted to work with overlays, completely | ignoring the possibility of distinct repositories. Overlays is | something that exists already and news support for them is a request | that will appear as soon as news support is added. Overlays don't contain metadata directories and don't get synced, so they don't contain news items. Supporting news from multiple sources is something that's tied to supporting packages from multiple sources, which overlay doesn't permit. Fixing that would require fixing portage to support multiple repositories rather than using overlay, which is an issue for a different GLEP. You can use gensync (included with gentoolkit). $ gensync --help Usage: gensync options repo-id-1 repo-id-2 ... where options is one of -a, --all-sources - sync all know sources -l, --list-sources - list known rsync sources -C, --no-color - turn off colours -h, --help - this help screen -V, --version - display version info Zac -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
Point of Clarity, and the ``mysql-5`` database format changes. These changes actually occured in mysql 4.1, not mysql-5 On 12/10/05, Ciaran McCreesh [EMAIL PROTECTED] wrote: Main changes since the previous edition: * File format tweaks. * Changes to the way relevance headers work to make it easy to do things like show this to gcc-3.3 users on x86 or sparc. * News items are no longer copied. This makes it considerably easier to install news items -- there's no longer a need to do clever directory syncing tricks. For those of you who can't read RST, an updated version will appear on the website sometime in the not too distant future. For those of you who can, see the attached. For the sake of keeping this vaguely sane, replies that meet any of the following criteria will be ignored: * Top or HTML posting * Lack of coherent English sentences, complete with proper punctuation and capitalisation. * The sender's first name ends in 'an', and they are not me. * Questions about why the GLEP doesn't address hypothetical vapourware concepts. * Questions about why the GLEP doesn't provide a way to tell users that there's a pissup at Reuben's house next Tuesday. * Questions about why the GLEP doesn't require integration with other systems, rather than leaving it merely as something that should be easily doable. * Anything involving XML. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Sat, 2005-12-10 at 22:31 -0500, Dan Meltzer wrote: Point of Clarity, and the ``mysql-5`` database format changes. These changes actually occured in mysql 4.1, not mysql-5 * The sender's first name ends in 'an', and they are not me. Um, your first name ends in 'an' so your reply is immaterial -- Homer Parker Gentoo/AMD64 Team Gentoo/AMD64 Arch Tester Strategic Lead Gentoo Linux Developer Relations [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
