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 spec
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
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. | What do you want, another glep amending yours with that one little | detail? Probably won't be necessary... | 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. | > | 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 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. | > 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. | 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. -- 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 Sun, Dec 18, 2005 at 12:14:30AM +, Ciaran McCreesh wrote: > On Sat, 17 Dec 2005 15:33:18 -0800 Brian Harring <[EMAIL PROTECTED]> wrote: > | On Wed, Dec 14, 2005 at 09:54:06PM +, Ciaran McCreesh wrote: > | > 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). > > It'll probably just be a case of updating news clients to query Portage > somehow for a list of repository IDs and using appropriately named news > files. Transitioning from single news.unread to N is going to break clients that expect a single. As I said, you're going to break stuff- and you're building it into your glep out of (aparent) stubborness. What do you want, another glep amending yours with that one little detail? Or someone just gets off their ass and tweaks your glep, gets another glep #, and stops the pointless arguing with you and pushes a competing glep? 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. > Hard to say for sure without details of how exactly multiple > repository support will work though -- for example, if you're going to > allow fancy characters in repository names then some kind of name > mangling standard will need to be defined. Standard ascii, same rules required for glep31. > | 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. > | 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. > > You're asking me to guess how Portage multiple repository support will > work, and then ask for a bunch of changes to Portage to support > appropriate dummy functions. I'll remind you that portage devs have stated this is required for your damn glep. Iow, collaboration here is required- work out the api that you need that fits in with what we need, instead of wasting our time arguing over whether you should do it or not. > Unless you're prepared to commit > yourselves to saying "multiple repository support will work like > $blah", I'm not going to even think about asking you to restrict > yourselves to a particular implementation... There's no asking here; you're pushing a glep, we've stated in it's current form constrains *our* efforts long term. Word games suck, instead of playing them you *should* be trying to address the concerns- iow, what do you *explicitly* need from portage, > 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". > | 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). > > That's not likely to be a major performance hit... We're not expecting > the user to have more than a few repositories, are we? Stated it to cut off any angle of "waah, can't go that route, portageq calls are to slow". Something your glep doesn't clarify and I want nailed down in stone (since at your request we are being explicit here), is how the 'package manager' is going to track news items that are marked as unread already, further the news.skip file. Basically... you're the glep author/champion, implementing the portage modifications are your responsibility (we may help, but it's your job to do it). Since
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Sat, 17 Dec 2005 15:33:18 -0800 Brian Harring <[EMAIL PROTECTED]> wrote: | 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). It'll probably just be a case of updating news clients to query Portage somehow for a list of repository IDs and using appropriately named news files. Hard to say for sure without details of how exactly multiple repository support will work though -- for example, if you're going to allow fancy characters in repository names then some kind of name mangling standard will need to be defined. | 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... | 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. You're asking me to guess how Portage multiple repository support will work, and then ask for a bunch of changes to Portage to support appropriate dummy functions. Unless you're prepared to commit yourselves to saying "multiple repository support will work like $blah", I'm not going to even think about asking you to restrict yourselves to a particular implementation... Especially since you've said "we're not doing it the way you think it should work"... | 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). That's not likely to be a major performance hit... We're not expecting the user to have more than a few repositories, are we? -- 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 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 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
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 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
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
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
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
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
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 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
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
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 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
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
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 repo-id-1 repo-id-2 ... where 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
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
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. -- 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: 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
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
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: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 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 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 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
Jason Stubbs wrote: [...] > 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. [...] BTW I love that feature ;-) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Monday 12 December 2005 18:30, Duncan wrote: > 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. This is only of concern to portage developers. > 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. 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. > 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. 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). > 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. 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. -- Jason Stubbs -- 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
