Re: [gentoo-dev] GLEP ??: Critical News Reporting
On Thu, Nov 03, 2005 at 08:24:27PM -0500, Nathan L. Adams wrote: > I'm also commenting on the part that *wrongly* states "It is not > reasonable to expect all users to have an MTA, *web browser*, email > client, cron daemon or text processing suite available on their system. > In particular, this means that any markup to be parsed must be in a very > simple format." > > *ALL* of the official docs are GuideXML; Gentoo *expects* users to have > a web browser by default. Otherwise a vast majority of users would never > get Gentoo installed in the first place. The "lightweight" requirement > appears to just be your way of subverting the current documentation > standards (because of your XML hatred). We actually have links in the base profile iirc, either way, the example of where this breaks down is headless servers... > The news directory shouldn't the main source of the migration guides; > the website should be (one central page that can feed other sources). Not necessarily the website imo, some central store where it's pushed out to all of the locations though (which I suspect you're getting at). ~harring pgpQZBR7QbbP5.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two
On Sat, Nov 05, 2005 at 12:58:14AM +, Ciaran McCreesh wrote: > Lightweight > It is not reasonable to expect all users to have an MTA, web browser, > email > client, cron daemon or text processing suite available on their system. > > Multiple delivery method support > Some users may wish to view news items via email, some via a terminal and > some via a web browser. A solution should either support all of these > methods or (better still) make it trivial to write clients for displaying > news items in different ways. Drop the lightweight bit and merge it into multiple delivery. You're after lightweight _default_, which is fine, but the phrasing is a bit screwed. > Quality control > There should be some way to ensure that badly written or irrelevant > messages > are not sent out, for example by inexperienced developers, those whose > English language skills are below par or morons. While it may be fun getting a reaction out of people, nuke the nitro laced words please. Same for the forums_whining ref (there's enough contention over the glep already ;) > 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. Out of curiousity, how are you planning on having 101 general notices reigned down on a users head during an initial install? Yes, you have the atom filter, but what about general notices? Further, how are notices going to apply to users who don't have the 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. > News Item File Format > - > News items may be signed using GPG. If this is done, a detached signature > should > be used. I'd argue for must be, personally. A bogus news item claiming to be from portage devs, telling users to change their SYNC setting could cause massive mayhem. > The following headers are used for filtering. If none of these headers are > specified, the news item is displayed for all users. Otherwise, the news item > is > displayed if *at least one* header matches. > > ``Display-If-Installed:`` > A dependency atom or simple package name (for example, > `` package specified installed, the news item should be displayed. Still haven't address my point about A) package moves combined with news entries B) N packages 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). Should clarify USE conditionals are a no go- might be worth considering the full atom syntax (despite the fact portage doesn't currently support it for depends), use flags, slot, etc. Yes it's more work, but it should be spelled out from where I'm sitting. > ``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. N keywords == N Header entries? > There have been complaints regarding the comprehensibility of some upgrade > notices and news items in the past. This is understandable -- not every Gentoo > developer speaks English as a first language. However, for the sake of clarity > and professionalism it is important that any language problems be corrected > before inflicting a news item upon end users. > > Thus, all proposed news items must be posted to the ``gentoo-dev`` or > ``gentoo-core`` mailing list No go on -core imo; it's a community/dev issue, should be visible to the general public rather then hidden away in the ml we do our flaming in. > Client Side > ''' > > Whenever relevant unread news items are found, ``emerge`` will copy or symlink > the news file into ``/var/lib/gentoo/news/``. Already pointed out that this won't fly looking forward, it implicitly assumes a single repository. Need to allow for each repo to have their own news, preferably seperated directory wise; either that or you're going to have to track where a news item came from and mangle the new entry. > Notification that new relevant news items will be displayed via the > ``emerge`` tool in a similar way to the existing "configuration files need > updating" messages: > > :: > > * Important: 3 config files in /etc need updating. > * Type emerge --help config to learn how to update config files. > > * Important: there are 5 unread news items. > * Type emerge --help news to learn how to read news files. > > The unread news message will also be displayed immediately after an > ``emerge s
Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two
Additional issue/question... On Sat, Nov 05, 2005 at 12:58:14AM +, Ciaran McCreesh wrote: > 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. > 7. The news item is handled by the user's choice of news item reader. See > `News >Item Clients`_. > > > Client Side > ''' > > Notification that new relevant news items will be displayed via the > ``emerge`` tool in a similar way to the existing "configuration files need > updating" messages: > > :: > > * Important: 3 config files in /etc need updating. > * Type emerge --help config to learn how to update config files. > > * Important: there are 5 unread news items. > * Type emerge --help news to learn how to read news files. > > The unread news message will also be displayed immediately after an > ``emerge sync``. Your example readers delete from the news directory, yet I'd expect that's not going to be desirable for all setups- nor is leaving the news item in the news directory, and having it flagged every sync by emerge as unread. Might want to consider some way to mark an item as read without waxing it from the directory, if against it, clarify in the glep why. ~harring pgpKWldQPcsrp.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two
On Sat, Nov 05, 2005 at 10:18:14PM +0900, Jason Stubbs wrote: > > ``Display-If-Installed:`` > > ?? ?? A dependency atom or simple package name (for example, > > ?? ?? `` > ?? ?? package specified installed, the news item should be displayed. > > > > ``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. > > > > ``Display-If-Profile:`` > > ?? ?? A profile path, for example ``default-linux/sparc/sparc64/server``. > > If > > ?? ?? the user is using the exact profile in question, the news item should > > be > > ?? ?? displayed. This header may be used to replace ``deprecated`` files in > > ?? ?? the future. > > Isn't keyword just a generalization of profile? Why have both? You would have to specify a common subprofile, and have the code know to dig through the ancestors of a profile. Breaks down when dealing with profiles that lack a common base (conversion from flat profiles to cascaded for example). ~harring pgp7ES8WE2LRE.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two
On Sat, Nov 05, 2005 at 05:45:35PM +, Ciaran McCreesh wrote: > | > News items may be signed using GPG. If this is done, a detached > | > signature should be used. > | > | I'd argue for must be, personally. A bogus news item claiming to be > | from portage devs, telling users to change their SYNC setting could > | cause massive mayhem. > > Signing elsewhere isn't mandatory yet. Deal with it ;) New additions to the tree that don't require signing just shove more load onto anyone who is trying to make the entire tree signed- you're already placing it in the tree so it doesn't make screw with future portage plans (news directory), this isn't much different. Note also I'm not stating your example clients must handly signing- it'll ugly up the trivial exmples a bit, but the messages delivered *must* be signed from where I'm sitting. It's easy to state that "well others don't have to sign"; the problem here is that you must start somewhere. If the whole effort of signing is abandoned, the restriction that all news items be signed is easily dropped- going in reverse (retroactively getting authors to sign their old news) is a bit of work that could be avoided. > | 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... Note it please; it's a concern. > | No go on -core imo; it's a community/dev issue, should be visible to > | 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. Valid point, which will hopefully be noted in v3 of the glep? :) > | 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. *cough* PORTDIR_OVERLAY *cough* Already have multiple repo support. Assumed you meant standalone, in which case I still think you're dodging support that must be there. Changing it after the fact because it wasn't design with an extra bit of forward thinking isn't something I'm incredibly game for. Yes it's extra work for you, but you're proposing the change ;) You're going for forward compatibility... this is just that. > | 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? Freaking annoying, is the technical term I use. ~harring pgpgXMPcJoSn7.pgp Description: PGP signature
Re: [gentoo-dev] Last rites for media-video/realone, media-video/realvideo-codecs and old versions of realplayer
On Fri, Nov 18, 2005 at 01:28:02AM +0100, Diego 'Flameeyes' Petten? wrote: > On Wednesday 16 November 2005 20:16, Mike Frysinger wrote: > > you asking or telling ? ?didnt you learn anything in elementary school ? > Is "rhetorical question" a new concept for you? Maybe I'm daft, but this OT cruft _really_ doesn't need to be winding up in the mbox's of everyone subscribed to gentoo-dev stop in other words, no one cares about the word games. ~harring pgpMrwBhkt1zd.pgp Description: PGP signature
Re: [gentoo-dev] Email subdomain
On Sat, Nov 19, 2005 at 09:16:06AM -0700, Lares Moreau wrote: > Is there a possibility to have each 'type' of staff have there own > subdomain. ie. @testers.g.o for at/ht > @docs.g.o for document persons > @infra.g.o for infrastucture > etc... > @staff.g.o for non-specific staff > @g.o for devs No (and hopefully this email finally kills this line of thought off :) fex, for me [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] (portage infra crap plus distfiles) ferringb@(recruiters|devrel).g.o (recruiters) for solar [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Etc. I'm naming subdomains off the top of my head to match high level grouping, but it should be clear this isn't a tenuable path to take both for devs, and for harassing infra with alias requests. > Further, have an alias from @g.o to @.g.o, with an email > returned to the sender if the subdomain is incorrect. Aliasing sucks due to the need to remove the alias after a role changes- if I stop doing recruiting, that alias now needs to be disabled. Either you bounce the email, or you leave the alias in place- either solution sucks if you're trying to do subdomains and have them actually mean something. This also is not even remotely getting into the question of segregating gentoo peeps, something I dislike. It's just not a good way to manage things with people changing roles, nor does the subdomain addition really mean anything imo- if I had all of those aliases, I'd still send from [EMAIL PROTECTED] Can't tell what the hell I do based upon the from, still would have to resort to doing some digging... ~harring pgp18Vo5v18cF.pgp Description: PGP signature
Re: [gentoo-dev] implementation details for GLEP 41
On Sat, Nov 19, 2005 at 05:06:15PM +, Kurt Lieber wrote: > For instance, the way GLEP 41 suggests doing r/o cvs is not going to work. > It suggests using a single account and placing an SSH key for each arch > tester in that account's ~/.ssh/authorized_keys file. text in question "Get read-only access to the gentoo-x86 repository. This doesn't have to be individual accounts, a single account, without a shell, with all of their keys will be sufficiant." Note the "doesn't have to be" and "will be sufficient", it's left open to how y'all want to implement it. > There are no provisions for key management and I cannot see an easy way to > handle it. It's easy to add new keys, but how do we clean out old keys for > retired arch testers? (including arch testers that "retire" without ever > informing us) SSH doesn't log key ID as near as I can tell, so we have no > way of tracking what keys are used and how often. Also, how do we > definitively correlate an SSH key with an arch tester? > > Now, the same question for email -- how do we manage aliases, especially > for inactive, retired and semi-retired arch testers? We could track usage > in logs, but between mailing list subscriptions, bugzilla notifications and > all sorts of other automated emails, that's not an accurate representation > of whether an email alias is actively used or not. > > I talked to Lance and neither he nor I were consulted about this GLEP and > how feasible the implementation is. We both are quite concerned about the > issues that I've outlined above as well as others. > > This isn't a "we're refusing to implement this GLEP" email, btw, though I'm > sure some of you will take it as such. It is, however, a "we were never > consulted regarding implementation details, so there are still issues that > need to be worked out before this GLEP can go anywhere" email. Cvs concerns above are all based upon doing single account for cvs ro; again, it's stated as an option (iow, the option is left up to y'all). It's not mandating anything on you for cvs, reread it if you don't believe me. It's stating the base, that they only need the users to have cvs ro access... Either way, it's word games, and yes, it's kind of retarded. ~harring pgpeRDvHy3OLW.pgp Description: PGP signature
Re: [gentoo-dev] implementation details for GLEP 41
On Sat, Nov 19, 2005 at 07:14:03PM +, Kurt Lieber wrote: > On Sat, Nov 19, 2005 at 08:03:55PM +0100 or thereabouts, Sven Vermeulen wrote: > > Isn't this an issue that also exists for the Gentoo developers in general? > > Not as much since we can track things like last cvs commit, last login to > toucan, etc. But it does exist to some extent. > > That does not, however, make it acceptable to further exacerbate the > problem. We're working towards improving the procedures and controls we > have in place today. We're not going to implement something that will move > us backwards. I'll again point out that the glep doesn't actually mandate it, states it's the lowest common denominator that's acceptable. Stop pointing at one interpretation of it that sucks, when the glep _does_ leave it open to you how to implement it. It's a waste of people's time and bandwidth, and is a bit disenguous. ~harring pgpopED2wW6i0.pgp Description: PGP signature
Re: [gentoo-dev] Email subdomain
On Sat, Nov 19, 2005 at 03:20:57PM -0600, Lance Albertson wrote: > Danny van Dyk wrote: > > > Please have a look at the council's meeting log. They said: > > a) the changes had been minor and exactly what the changes they wanted > > in in the first meeting. > > Minor? What you're asking for will cause a lot of administrative > nightmare for infra to manage those subdomain addresses among other > things. Frankly I think you're exagerating here. You're seriously telling me it's going to cause you massive adminstration nightmares adding an attribute to ldap to specify the user comes in from a subdomain? Where's the nightmare in admining it? It _should_ just be a setup cost. If that's not the case, I question your setup. > I would have preferred that the people involved with this could > have directly asked infra if this would work for us. That's a simple > request that I did not see from these folks. It's a crazy notion, but y'all could've commented in the *TWO* months that this glep has been percolating, "yo, what do you want from an infra standpoint?". Or implemented anoncvs in the meantime, thus nuking the main request that's being made of infra. > > b) they stated that this is the first and the last time that a GLEP will > > be voted on if that hasn't been discussed sufficiently long enough on -dev > > Good, so lets please fix this current GLEP before we implement it. I > don't like the answer of "they voted on it, so do it". To me, they voted > upon it without following their new mandate on discussion of GLEPs > before the meeting. The whole point of GLEPs is discussion to make sure > we don't make mistakes, especially if revisions were made. Just because > it follows the mandates of what the council wanted doesn't mean it > shouldn't be discussed again on -dev. I trust the council's decisions > and commonsense, but there still needs to be input from the masses to > ensure details are worked out BEFORE they are voted upon. > > Simply saying "we'll have a subdomain for new email addresses" without > asking infra about it first negates the vote in my eyes because we > weren't properly involved in the discussion process which was skipped > for the revision. We're the ones that will be put on the task to > implement it, yet never got any direct input from the people who wrote > this GLEP. It is your guys responsibility to keep up to date on what's underway. Portage devs do it, arches do it, infra is no different. That's why you're on this ml- that is why gleps get sent to this ml- so that all of the various groups can weigh in. > > c) that new limitations for a vote are: send (revised) glep to > > gentoo-dev (at least) 14 days before the next council meeting, ask (at > > least) 7 days before the meeting for vote. (For this you can also read > > seemants mail announcing the availability of the logs) > > Great, so lets negate the vote and do the right thing for this current > GLEP. I don't see the point of letting this one pass by especially since > the GLEP folks even said themselves they could wait. All I'm after is > doing this the right way instead of shoving it under a table and just > forcing the issue. I would prefer this be corrected as stated above with > proper discussion instead of saying that its already be decided on so do it. So... infra can bitch, and have the council vote reversed? What about portage group, do we have the same power? QA? Devrel? Y'all haven't offered any input into this glep in the 2 months it's been around. Further, *you* did see the glep, and didn't get off your ass and state "hey guys, this has to be delayed- infra needs to review it". You guys want the glep changed, either ask hparker and crew nicely, or submit your own glep. You've had time to be involved, and you've admitted you saw but did not even comment "we need to review this, it must be delayed". > Can some of the council members please comment on this? I'm curious > their thoughts on this. Maybe I'm just barking up the wrong tree, I just > see this as a terrible miscommunication between the GLEP authors, the > council, and infra. I see this mainly as infra/trustees not watching the ML. Lance, I know you try to keep up to date and involved. Corey thus far has made lovely accusations towards the council without even _reading_ the damn meeting log. We already know klieber didn't even know about the meeting log/summary that was sent to this ml (and kicked off this thread). Frankly it seems like y'all didn't pay attention, and got caught with your pants down. Sucks, but too damn bad. And no... bitching about the window for the revision isn't really valid, since the requested revisions to the glep from the council have been known for a month already (again, more then reasonable time to know what is afoot). > The council and GLEP authors were in line, but > weren't in line with infra. I would just like the vote to be > reconsidered or postponed until we properly co
Re: [gentoo-dev] implementation details for GLEP 41
On Sat, Nov 19, 2005 at 10:03:58PM +, Kurt Lieber wrote: > On Sat, Nov 19, 2005 at 01:51:15PM -0600 or thereabouts, Brian Harring wrote: > > Stop pointing at one interpretation of it that sucks, when the glep > > _does_ leave it open to you how to implement it. It's a waste of > > people's time and bandwidth, and is a bit disenguous. > > I'm trying to find a solution to the issues as I see them. Telling me I'm > wasting people's time and bandwidth doesn't seem conducive to working > together towards a resolution to this all. If you're going to say, "it was > passed, you guys just have to find a way to implement it. now please stop > bothering us" then I'm going to come up with an implementation plan that > looks something like the following: > > * all SSH keys and email addresses for arch testers will auto-expire after > 60 days. If an arch tester needs to have continued access, a gentoo dev > will have to re-submit the key and recreate the alias for that arch > tester every 60 days. > > That meets the requirements of the GLEP down to the letter and also > satisfies infra concerns around key management. However, it's a crappy > solution. > > So, I'd much rather work together towards finding a better one. Simple solution, that I've repeatedly pointed at. Use the existing ldap setup. It's not infra's responsibility to add their accounts nor disable them (that is left in the air as stated, although I'd expect it'll fall on devrels head). Infra doesn't even do retirement beyond when _devrel_ asks them to. If that process is slow, ask for help and someone will chip in and improve it (mainly to minimize bottleneck involved). A simple script handling a pull from ldap sshPubKey attribute updating $USER/.ssh/authorized_keys on lark, you've got the cvs ro issue licked. Doesn't require anything crazy/new, and could be implemented in no time- no infra overhead beyond an initial setup cost for cvs, which I would be willing to implement myself. It's minor to do it within existing framework, which is why I've stated it's daft pointing at the minimal requirement as admin hell. ~harring pgp4TKmuIRnQz.pgp Description: PGP signature
Re: [gentoo-dev] Email subdomain
On Sat, Nov 19, 2005 at 03:27:52PM -0700, Tres Melton wrote: > staff.gentoo.org forum staff > amd64-at.gentoo.org Arch testers for the amd64 platform > contributer.gentoo.orgPeople that donate $$$ to Gentoo > retired.gentoo.orgA thanks for helping earlier domain > > For the developers like ferringb, solar, vapier, etc. that have many > roles perhaps they could have the subdomains forward to their > @gentoo.org address. But then again that complicates things for the > -infra team which I don't want to do. That is why I've tried to keep > quiet. There is still quite a bit for me to learn. Easier, and saner to just plain drop the subdomain notion. Avoids the whole gentoo personel first class/second class issue first of all, second avoids infra aliasing annoyances. Note also that retired.gentoo.org shouldn't really accomplish anything, unless the dev is able to send through the account (if they're retired, I would posit they shouldn't be able to). > deltacow stated that in IRC... and my response to that is: "that is > what IRC cloaks are for". Voice is used to mark AT's in #gentoo-amd64 > but the voice is used mostly for tor users in #gentoo. I don't want to > open a new can of worms by bringing in IRC but there really is no > standardization throughout the channels and I think that is the way that > most people want to keep it. I'm not suggesting anything until I learn > more. Subject for another glep I'd think, although tbh not something I personally have much interest in- rules and conventions across channels vary fairly massively. I wouldn't be too happy if the language requirement wound up forced on #gentoo-portage for example (nor do I suspect would the hardened crowd) :) ~harring pgpzRprdiBAvq.pgp Description: PGP signature
Re: [gentoo-dev] implementation details for GLEP 41
On Sat, Nov 19, 2005 at 10:47:37PM +, Kurt Lieber wrote: > On Sat, Nov 19, 2005 at 04:30:53PM -0600 or thereabouts, Brian Harring wrote: > > Infra doesn't even do retirement beyond when _devrel_ asks them to. If > > that process is slow, ask for help and someone will chip in and improve > > it (mainly to minimize bottleneck involved). > > OK, fine. Devrel does not have an established track record of retiring > devs who are otherwise inactive. Please fix this. Please also get an > agreement from them that they're going to be willing to take on the > additional load of these arch testers. Then please articulate the process > that will be followed to ensure they're actively tracked and retired > if/when they fall off the map. Devrel doesn't have much issues in actually retiring a dev from where I'm sitting. The problem is in detection- an infra issue that could be solved by either allowing normal devrel people to run the detection scripts themselves (rather then asking infra to do so), or in modifying the commit hooks so it pushes info into ldap (which we can access). Again... setup cost (something I'm more then willing to implement). ~harring pgpVUeTbvlTIi.pgp Description: PGP signature
Re: [gentoo-dev] Email subdomain
On Sat, Nov 19, 2005 at 04:46:51PM -0600, Lance Albertson wrote: > Brian Harring wrote: > > It's a crazy notion, but y'all could've commented in the *TWO* months > > that this glep has been percolating, "yo, what do you want from an > > infra standpoint?". > > > > Or implemented anoncvs in the meantime, thus nuking the main request > > that's being made of infra. > > What was posted two months ago is not the same as was posted a day > before the vote. I didn't see a problem with the original glep from an > infra POV, thus why I didn't say much about it. Email wise, you're right- the basic issue of anoncvs/cvs ro access for ATs however has been in the glep from the beginning (regardless of the glep having a minimal req tacked into it). That said, the subdomain bit has been available since the oct council meeting. Not something that was particularly sprung, although grounds for arguing that it wasn't pushed out in the best manner. That still doesn't address my point about the basic need of the glep, anoncvs/cvs ro being known. > > It is your guys responsibility to keep up to date on what's underway. > > Portage devs do it, arches do it, infra is no different. > > > > That's why you're on this ml- that is why gleps get sent to this ml- so > > that all of the various groups can weigh in. > > The revised GLEP in question was posted a day before the vote. I was > watching it, though I didn't get a chance to read through the whole GLEP > for the changes at the time since I was busy with real life issues. This > is why I stated in an email [1] that day that they should postpone > voting on it. > [1] http://marc.theaimsgroup.com/?l=gentoo-dev&m=113199543120777&w=2 Reading through it, it reads more like a comment about the process. It's also not an explicit request that it be delayed, which I'll assume is just me misreading it. > > You guys want the glep changed, either ask hparker and crew nicely, or > > submit your own glep. You've had time to be involved, and you've > > admitted you saw but did not even comment "we need to review this, > > it must be delayed". > > Considering how the revised GLEP went through without ANY discussion > prior to the vote, I don't see why we need to. That is an issue of the > procedure used to to get this GLEP approved which wasn't done correctly. > I have yet to see a valid reason for pushing ahead for the vote (and > yes, I read the log.. see my comments in previous emails about that > logic they used). Said hole has been closed; what I'm stating is that y'all should work through what's available rather then a forced re-vote. See tail end of email for reasoning. > > I see this mainly as infra/trustees not watching the ML. > > What does trustees have to do with this GLEP? And yes, I was watching > the ML, but giving me 24hr to respond to a GLEP revision before a vote > is not reasonable. Knowing what the revisions where going to be (previous meeting) makes the 24 hour comment a bit off. > > Frankly it seems like y'all didn't pay attention, and got caught with > > your pants down. > > Thats not the case, we got a revised GLEP one day before the vote and > didn't have a chance to reply reasonably. Email is about the only snafu out of this whole thing that is reasonably questionable imo. Concerns about load on lark, handling the new users, etc, no, as I stated, this glep has been around for 2 months without infra asking what's required. That's the crux of the "caught with the pants down". The fact that the initial glep could've passed, and still there would be complaints/issues brought up (beyond email concerns) afterwards because people didn't pay attention. > > Sucks, but too damn bad. > > I'm not going to reply to that. Probably wise, since it wasn't a friendly jab on my part (for which I should be duly flogged). > > And no... bitching about the window for the revision isn't really > > valid, since the requested revisions to the glep from the council have > > been known for a month already (again, more then reasonable time to > > know what is afoot). > > Where was it stated that it was posted and was being discussed? Just > because it was stated in a meeting log and was committed in cvs doesn't > mean I need to read cvs changelogs. I expect the information about the > GLEP i need to know about to be in the GLEP and that the revised GLEP to > be sent with ample time before the meeting at hand. This was not done > and this is why I'm frustrated with the situation. Again.. as
Re: [gentoo-dev] Email subdomain
On Sat, Nov 19, 2005 at 03:06:41PM -0800, Corey Shields wrote: > On Saturday 19 November 2005 02:19 pm, Brian Harring wrote: > > > Minor? What you're asking for will cause a lot of administrative > > > nightmare for infra to manage those subdomain addresses among other > > > things. > > > > Frankly I think you're exagerating here. > > What about the end-user headache of having to change subscriptions/bugzilla > accounts/aliases/etc. from [EMAIL PROTECTED] to > [EMAIL PROTECTED] should they turn dev? Same rules that already are forced upon devs when they make the change. It's not really an AT specific issue. Bugzie changes are handled by the devrel monkey who is converting the user over, ml, the user has to do the re-subscribe on their own. If you're after changing that process, hell, that would be nice, but it's a global issue, not AT specific. It's not a blocker for AT's, since it's a global issue. > > It's a crazy notion, but y'all could've commented in the *TWO* months > > that this glep has been percolating, "yo, what do you want from an > > infra standpoint?". > > Yeah, my bad.. Had I known that infrastructure implementation decisions > could > be decided by a GLEP with no infra input requested, I would have paid > attention. > > Besides, when I first read the glep "*TWO* months ago" there was nothing > about > email subdomains.. It was fine.. Therefore, I did not comment. See email in response to lance. Two months is applicable for the cvs requirements... > > I see this mainly as infra/trustees not watching the ML. > > Foundation has nothing to do with this issue whatsoever. Strangely, my mentioning of it is related to my (perhaps crazy?) view that trustees should be watching what's going on with gentoo- the main comment in the email is that at least the changes were known for a month via the managers meeting is where the issue comes in. You *should* be following the council's actions in my opinon. Perhaps my view is flawed/stupid, but y'all are the stewards of gentoo. I expect you guys to be rarely surprised by proposed changes. > > Sucks, but too damn bad. > > So will be finding help from infra to implement this with that attitude. > You're not helping the situation, Brian.. Kind of took that one out of context- the comment is in regards to waiting till after something occurs to start complaining about it. Subdomain complaints, fine, I'm not even going to argue that one at this point, the actual cvs enabling, you should've known it was coming- being surprised by it sucks, but so does trying to revert it because it surprised you. > I corrected my wrong in this thread, > but I still feel that the lack of delay between the changes and the vote was > not enough for devs to comment (specifically Lance). I don't care if I am a > trustee or not, that's wrong. After your last email, I don't think you are > in any position to comment on behaviour. ;) Still stand by the email, surprisingly. Thing is, you haven't corrected 'your wrong', and if you had just *stated* the concern from above, rather then "Lesson learned, make friends with a majority of the council, write and propose a glep the day before a meeting and then push it through. wow. sounds a lot like American politics." I wouldn't be pointing to it as abhorrent behaviour that is cabal fodder. Baseless accusations don't usually result in people liking what you're saying, even if you retracted the "council members voting on stuff they didn't know about" claim. If you can't see that, well I'll shut up on the point (others have already pointed out it was a bs statement). ~harring pgpRqZqykCO7H.pgp Description: PGP signature
Retiring devs [was Re: [gentoo-dev] implementation details for GLEP 41]
On Sat, Nov 19, 2005 at 11:04:44PM +, Kurt Lieber wrote: > > The problem is in detection- an infra issue that could be solved by > > either allowing normal devrel people to run the detection scripts > > themselves (rather then asking infra to do so) > > First I've heard of this request. Has a bug been submitted for it? It's > easy enough to set up some cron jobs to run scripts and email output to an > alias or mailing list. Only the usual irc infra requests (will take that comment as indication it's time to open a bug). Would need the ability to maintain a blacklist of users to auto-ignore (releng), and would need to pull from svn also (something the current script doesn't handle afaik). Binding pulling buzilla stats in would be needed also (poke kloeri about that one). Ultimately, tracking actual pulls (ssh access on lark) rather then just pushes would be needed to- otherwise new doc devs, AT's, and new alt devs would be flagged due to their lack of the write bit. Forums people, any thoughts/requirements? ~harring pgpuXxuQuUhQ5.pgp Description: PGP signature
Re: [gentoo-dev] Email subdomain
On Sat, Nov 19, 2005 at 06:05:18PM -0600, Lance Albertson wrote: > And yes, we probably could/should have said something > about lark earlier, but didn't catch that before hand. Shit happens (lark). The appearance/concerns of cvs (specifically the "this won't fly if it's single key") is what I'm pointing at here. > >>>Sucks, but too damn bad. > >> > >>I'm not going to reply to that. > > > > Probably wise, since it wasn't a friendly jab on my part (for which I > > should be duly flogged). > > I was rather disappointed in the unprofessional ism of that comment. Eh, I don't have the tolerance you do. :) The phrasing was intended to make it clear that people not tracking what's going on, then getting bit in the ass by it are to some degree at fault. See the apache complaints, and ensuing emerge --news for reasoning behind this one (and yes, the question of how best to push the info out is an issue, but it still requires proactive measures from the people affected). > Solar even mentioned it DURING the meeting to hold on the vote. But > everyone else thought that everything was covered and passing it > wouldn't cause a problem (which was incorrect). Solar got overruled. majority vote... > The hole was closed after they decided on the GLEP. That doesn't make > sense. Why make a rule for it while ignoring the current situation at > hand? This GLEP was the whole reason they added that stipulation, and it > made no sense to me why they didn't apply it to this GLEP they voted > upon. They have the power to do it if it out of common sense. > > Specifically reverting/changing a glep. See glep1 for actual process, > > or nudge glep41 authors to revise and get council to sign off on it > > (that chunk is somewhat unspecified procedure wise). > > After we sort out details on our end, I might do that. I'll gladly shut up in that case. The concern I have is that the council got stuck in a nasty position, and choose what they thought was an acceptable solution (and modified things so that scenario should never occur again). Reversion based upon next day ml complaints I'm not much for since A) the concern was there, and they made a decision (contraversial or not). B) reverting the decision is doable via existing methods, a call for reversion on the dev ml isn't really one of them (imo). Why am I being a stickler on this? Reversion via ml complaints after the decision opens the door for vocal minorities to try and revert gleps they dislike, rather then having to force their ideas/goals/changes through normal processes (where people can nuke the bad idea/infighting out via normal means) The concern _was_ leveled during the meeting, and decided to move forward. Decision was made. Reverting it (in this case) is a glep thing. Asking the council to reconsider something, well, no procedure (frankly I don't think one is needed either), but it would have to be something that occurs on normal schedule, and would be dependant on the council agreeing to reopen discussion. Considering the nature of this scenario, I *still* posit it's glep territory, through and through. Note that last paragraph is not from any documentation- just a dump of what I think would be wise/best. Everything following really should be chunked off into another thread to iron it out, since it's not glep41 related (although g41 is the catalyst for it). > > re-read it, not implying you are, what I'm stating is that no _group_ > > should have the ability to effectively force the council to > > revert/revote on a decision. Doing so means the council loses the > > ability to have issues passed up to it, and have it agreed upon gentoo > > wide, and have people actually move forward on something. > > > > Portage shouldn't have it, nor devrel, nor QA, nor infra (obviously my > > opinion). > > > > And yes, I'm well aware some day a brain dead glep may get forced > > onto the portage group, in which case feel free to taunt me with those > > words. I'll still stand by my statement from above, despite whatever > > nasty thoughts may be running through my head. :) > We're all busy, and we're all prone to miss details of happenings that > go on. If infra is going to need to implement something, I would prefer > the folks involved to either email us directly, or come in our channel > talk with with us directly about their proposal. I know I could have > followed the email/glep to get this information, but as you have seen, > we have busy lives outside of Gentoo and can't keep up with everything. > The proper thing for them to do would ask us directly about the proposal > instead of just assuming we watch every single flame email we see on -dev. Personally, I agree within limits. It's not the case currently though (eg, it's not grounds for forcing a reverse of their decision imo). > > Which opens up an interesting question of how to get the council to do > > a re-vote on something, something that should be a
[gentoo-dev] New Dev: Thunder
Hola list, Damian Florczyk has joined the Alt project to help with the FBSD port, and NetBSD port he's been working on externally. He's 22. lives in Wroclaw (Breslau) PL, and is in his third year of CS. It goes without saying that now would be the time to unleash a few "BSD is dead" jokes (might as well get them out of you system). :) Please make 'em feel welcome. ~harring pgp1HVVp8FL39.pgp Description: PGP signature
[gentoo-dev] New Dev: Jeroen Roovers aka JeR
All- Jeroen Roovers, mentored by gmsoft, is joining up to help the HPPA crew. In his words, I have lived in the Nederlands all my life and still intend to change that. I am married and I have two children (now aged 5 and nearly 4). I enjoy music, reading and toying with all the computer systems that keep my office dry and warm, although I also love being outside (webcam available at http://www.xs4all.nl/~rooversj/webcam.html ). I currently translate books and articles for a living, mostly on IT related subjects but occasionally fiction, history or (pop) music. Everyone please give Jeroen a warm welcome- as always, feel free to rib him a bit in irc (look for the nick ReJ, since JeR was long since taken). ~harring pgpOnX09VE0ob.pgp Description: PGP signature
Re: [gentoo-dev] Re: Decision to remove stage1/2 from installation documentation
On Tue, Nov 22, 2005 at 11:36:01PM -0600, Dale wrote: > R Hill wrote: > Getting a sync past 50% with slowing to a crawl > would be nice. Plenty of people complaining about that. > > Don't beat me to much OK. Be gentle. Really need to release a portage that contains http://dev.gentoo.org/~ferringb/blog/archives/2005-10.html#e2005-10-12T23_59_53.txt ... ~harring pgpIo0k8kZAQH.pgp Description: PGP signature
[gentoo-dev] New Dev: Marien Zwart (marienz)
Hola all. Please welcome Marien Zwart, aka marienz to the crew. He's joining up as a python monkey, working on twisted (2.x stable ebuilds anyone? ^.^), portage 3 hacking, and pretty much anything python wise. Finally, he's been helping out in #gentoo for quite some time. His words- From Groningen, the Netherlands, where I study physics/mathematics. Interests: general messing around with computers, used to do scuba diving but haven't gotten around to it much recently, sailing, listening to and making music (I play keyboard). Oh, and one thing I'd like to add since I think I've seen bits snipped from this in new dev announcements: sorry people from New Zealand, contrary to what some people think my nick does *not* stand for "Marie from New Zealand", it stands for "Marien Zwart", I'm male, and I live on the opposite side of the globe. Please take a moment to make him feel welcome, and make the usual attempt to dump bugs off on the new blood. :) ~harring pgp8SHMkcVPZr.pgp Description: PGP signature
Re: [gentoo-dev] enewuser/enewgroup getting their own eclass
On Wed, Nov 23, 2005 at 01:15:52PM -0500, Chris Gianelloni wrote: > OK. I've been looking at some of these issues we've been having, and > I've been thinking of moving enewuser, egetent, and enewgroup to their > own eclass. This will resolve some issues with things in system, or > otherwise early on, requiring shadow on Linux to get useradd. Two > examples of this are bug #113298 and bug #94745. By putting them in > their own eclass, we can keep from adding shadow to DEPEND in eutils, > while still putting the dependency in the eclass that uses it. You do this, and you'll break binpkgs that rely on it existing in eutils. Yes it's annoying, but you _have_ to lead the functionality in eutils, duplicating it into whatever class you shove it into. That's the other side of the "can't remove eclasses" rule- can't yank functionality that is going to break installed ebuilds and binpkgs. > I'd be willing to make all the changes to the tree to facilitate this, > and unless someone has a really good reason not to do so, I think I'll > probably do it after the Thanksgiving holiday. I'd delay this a bit personally, since it's a widespread change, and because people are probably going to be offline due to holiday cruft. Yah... you probably have the time to do it during the holiday stuff, but again, affecting a sizable collection of packages and requires ebuild devs to change the eclasses they're using. Plus the binpkg issue from above. ;) ~harring pgpX1g6QWYb1d.pgp Description: PGP signature
Re: [gentoo-dev] http://people.gentoo.org/
On Mon, Dec 05, 2005 at 06:39:45PM +0100, Henrik Brix Andersen wrote: > Allowing toucan:~brix/public_html/ to be accessed under either of the > http://dev.gentoo.org/~brix/ and http://people.gentoo.org/brix/ URLs? *cough* http://www.gentoo.org/~brix No clue if that's a hold over from older days, but perhaps that redirect might be inline with what you're after. ~harring pgpXo4YWwcro8.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
4am, pardon typos...
On Fri, Dec 16, 2005 at 03:56:30AM +, Ciaran McCreesh wrote:
> On Thu, 15 Dec 2005 22:34:05 -0500 Andrew Muraco <[EMAIL PROTECTED]>
> wrote:
> | 2. What choices/options are on the table for this feature?
>
> The big controversy seems to be over whether repositories carry a
> unique identifier string (for example, in metadata/repository_id) or
> whether it's user-assigned. The former is clearly the more sensible
> option, since it lets you do things like (syntax made up):
>
>
> *shrug* But it seems the Portage guys want repository names to be
> user-assigned, which makes them far less useful.
You seem confused.
Unique repo ID added to atoms? Bit bastardly imo, but that's
needed down the line at some point- extension of depset syntax either
way isn't a hold up on true portage N repo support. Makes it a
helluva lot more useful, but just making it clear that N repo doesn't
require depset extension, such an extension would be a feature, not
a req.
Either way... minor comment on existing, and what's needed/intended.
Existing /etc/portage/package.* layout is inherintly single repo in
design- bastardizing the atom spec just to resolve that is daft.
What's needed is an extension of the portage configuration so that
it's able to specify multiple standalone repos, slaved (overlay) repos
chained against the standalones, package.* filters applied to each
repo, etc. Config design that's sitting in savior actually handles
this (eg, you can bind whatever crazy set of package.* visibility filters
you like per repo), *although* it _requires_ the user to uniquely
identify the repo. Why? Well portdir as a magic constant doesn't cut
it in a potentially N repo environment.
Why is this a user configurable option?
User's choice for emerge --repo ${repo_label} sync.
This in no way blocks an internal repo ID being used- it's _merely_
the local name that's bound to the repo, thus please stop the "user
configurable repo labels is stupid" angle, since it's effectively
the user facing alias/handle.
Local news delivery *should* still be using the user label. Unique
repo internal labels don't matter to glep42, since the label that news
delivery _should_ use is what the user's configuration has named it.
Just stating it, since tagging a unique id into the repo isn't a hold
up for glep42. What is an issue with glep42 is planning for N repos,
eg another level of dirs/indirection as has already been stated.
~harring
pgps1aZnnUTKY.pgp
Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Sat, Dec 17, 2005 at 03:48:05AM +0100, Luca Barbato wrote: > >Just one remark: What about making the syntax a bit more familiar to C++ > >users: > > > >~ DEPENDS="gentoo-foo::foo-bar/baz-2.1" > > > >Comments? > > > > what about > > DEPENDS="gentoo-foo/foo-bar/baz-2.1" No, screws over >1 depth categories. ~harring pgp2Lc90jY8vS.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Sat, Dec 17, 2005 at 09:21:45PM +, Ciaran McCreesh wrote: > On Sat, 17 Dec 2005 13:16:04 -0800 Zac Medico <[EMAIL PROTECTED]> wrote: > | Ciaran McCreesh wrote: > | > Well, that depends... If you have sys-apps/foo installed from the > | > gentoo-x86 repository, and the breakmygentoo repository issues a > | > news item about sys-apps/foo, should it be displayed? > | > | Well, probably not. Off hand, perhaps portageq could provide a query > | that returns some type of UUID for a package, such as a hash of the > | ebuild. That way, the hash from /var/db/pkg could be compared to the > | hash from the repo that has the news item. If the hashes don't > | match, then the news item is irrelevant. > > Now do you see why I don't want to touch multi repo support without a > proper specification describing how it'll work? :) Multi repo support is actually pretty simple, and doesn't require yet another glep/spec/paperwork- it's been sitting in the saviour branch for as long as the domain class has existed (3+ months); stand alone repository support (matching within that repo) is a resolver thing, where we're at in saviour is normal PORTDIR capabilities for all specified repo's (standalone, overlay, or otherwise). It's not that bloody hard to get it working- all of the noise here is about further additions to it (which is fine, but kindly rememeber that fact), noise which I'd *rather* see resolved down the line. Why? Frankly, the majority of this is portage internal crap. Either extension of portageq api, or extension of atom syntax. Unique ID's per packages isn't a good idea offhand. What's needed for the comments above is the ability to search installed pkg db's for pkgs yielded from repo ID x. Enter the restriction subsystem. Add a repo level matching class, and you've got the search right there. Pretty simple, actually, and not requiring yet another glep for saviour. Back in the land of stable, here's how it should be done- portageq root atom [repo id] ex: portageq / sys-apps/foo "break my gentoo" simple mod. Lack of repo id is old rules, match anything and everything. This actually can be implemented *now* without requiring a bunch of handwaving about specs/gleps. Next issue? ~harring pgp1aAP8lv5g0.pgp Description: PGP signature
Re: [gentoo-dev] draft glep: multi-repo
Pardon bluntness; don't mean offense, just specifically picking the hell out of this proposal to make a point (lucky you) :) On Sat, Dec 17, 2005 at 03:17:44AM -0500, Andrew Muraco wrote: > Attached is a draft of a glep for formalizing multiple-repository support I appreciate trying to chip in, but frankly this glep needs a lot more thought put into it. Further, I _really_ do not see the point of glepping this either. Puking up proposals due to folks making noise is a waste of time- don't document/propose just because folks are making noise- do it for large scale changes, or conflict, not because someone requires a glep/spec before they're willing to listen to the _developers_ of a project about how to integrate a new feature into _their_ project. > This is far from ideal in many ways, but i'm too tired and I drank too > much caffine to be sane. > > Comments, objections, anything consructive is welcome. Inlined... > Abstract > > To implement a functional and expandable method for Portage to support > multiple repositories. > > Motivation > == > Multiple Repository support is needed, this GLEP is to address this need. define multiple repository. We _have_ multi repo already (binpkg and portdir, let alone overlays). > Specification > = > > Portage will make use of two (2) ways to address repositories: > * A User-defined name, which is likely to be used as a convinance in most > situations - this will be referred to as REPO_NAME in this GLEP > * A hard-coded repository-id which will be found in the repository tree > at: metadata/repo_id - this will be referred to as REPO_ID in this GLEP > Both names will contain no spaces, and only standard characters [TODO: > references] Portage externally will use user defined, internally it will do it's own thing. > Repositories > > > Each repository will contain: > * the repo name in metadata/repo_id > * repo information such as maintainer of the repo, notes on who hosts it, > etc will be contained metadata/repo_info > * unique packages.mask which will only apply to ebuilds within that > specific repo. > > The REPO_ID must match the name that will be used for rsync > Therefore, rsync://MyServer.tdl/REPO_ID/ No. It's arbitrary, and invalid to assume rsync is the only sync uri that's going to be used- this isn't even getting into _remote_ repos. *ANY* unique id tagged into a repo is just that, a magic constant in it's metadata. Just that. No mandates about SYNC, file layout, etc, will fly that bind to the metadata id. > /etc/portage/* > - > > In order to provide users with the current set of options and extend them so > they can be customized to each repository, the structure of /etc/portage > will remain similar with these changes: > * /etc/portage/REPO_NAME/* will be the location of repository-specific > portage files. > * /etc/portage/ will continue to function over all repos > ** ex) =sys-devel/gcc-4 -* in /etc/portage/package.keywords would use the > latest gcc-4 regardless of what tree it comes from. > > The following new files will be added to /etc/portage: > * /etc/portage/repositories.perfer - will contain each REPO_NAME in order > of preferance, higher is more perfered. (Each REPO_NAME will be on a seperate > line) yuck. This is a bit of a waste for a single file. > **In the absence of this file portage should use repositories in > alphabetical order. directory returned ordering, not alpha- no ordering == set of repositories, thus don't try to induce a fallback ordering. > * /etc/portage/REPO_NAME/repository.id - contains the specific REPO_ID > which REPO_NAME applies to. This is going to induce more slowdown for any config instantiation- more directories/files to scan. Iow, python -c 'import portage' (which instantiates a config obj), is going to get slower, which will piss off the slower system folk even further (hell, even with 1.5ghz and decent IO it still is a 10s import for me uncached). > */etc/portage/REPO_NAME/repository.conf - will contain any > repository-specific options, which can include, but is not limited to, > FEATURES="" C[XX]FLAGS="". > **This will also include a new variable; OPTIONS="" of which is similar > to FEATURES, but modifies the way portage will handle that specific > repository. > A few examples of options which could be useful: This seems a bit arbitrary. > *** EXCLUDESYNC - Prevents portage from doing a sync on this repo. And how are you going to specify the sync method for that repo? > *** EXCLUDEUPDATE - Prevents portage from using ebuilds in this repo as > updates for packages which currently reside in a different repo. > *** EXCLUSIVEUPDATE - forces any update to any package which is from this > repository to a newer version which resides inside of this repo. And this is implemented how? Why is it specifying resolver directives as r
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] draft glep: multi-repo
On Sat, Dec 17, 2005 at 11:25:58PM +, Ciaran McCreesh wrote: > On Sat, 17 Dec 2005 15:15:48 -0800 Brian Harring <[EMAIL PROTECTED]> > wrote: > | True stand alone repository capabilities aren't required/bound to > | glep42, all that's required out of glep42 is that the syncing repo id > | be used now (even if it may seem superfluous). Iow, news *should* > | work regardless if it's an overlay or a stand alone repo. > > Not quite true. I also need to know how to handle Display-If-Installed > and Display-If-Profile headers with multiple repositories. Hence why > I'd prefer to leave it as "something that can easily be implemented in > the future"... News is repo specific. What I stated in the glep42 thread email covers this already; zmedico already adress Display-If-Profile (namely, a simple portageq extension). What remaining straw men are there for ignoring the portage developers requests? ~harring pgpUt42bTyTFp.pgp 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
Re: [gentoo-dev] draft glep: multi-repo
On Sun, Dec 18, 2005 at 12:24:48AM +, Ciaran McCreesh wrote: > On Sat, 17 Dec 2005 16:14:15 -0800 Brian Harring <[EMAIL PROTECTED]> > wrote: > | What remaining straw men are there for ignoring the portage > | developers requests? > > Asking you to specify how multiple repositories will work before I try > to extend the GLEP to support multiple repositories is hardly a straw > man argument. Do you need to know how every bit of a car works to drive it? No. We're simply asking you to tag in a repo_id to your calls to portage. It's bloody simple, just need to know what you explicitly need from a news client standpoint. Stop being a stubborn mule, and realize that you're trying to shove a feature into portage that *we* have to maintain, including your built in design flaw for N repos. If you can't accept our criticism and suggestions for your glep, tough cookies, we're the ones stuck maintaining it, and the users are the one stuck when we expand portage functionality (thus breaking your implementation). > *shrug* But if you prefer, I'll change the GLEP to > support multiple repositories the way I'd like to see them done rather > than the way you'd like. Ciaranm, cut the word games and stupid threats. If you can't work with others, and actually understand that they may not agree with your views (let alone be willing to have you dump a mess on them), I suggest you leave the distro and go work on your social skills. Propose the glep however you want. As long as the glep is around, I'm going to do the same you do- point out the flaws in it. If you're unwilling to even nail down what is needed so that all parties are happy, that's fine- I would expect the council to realize the glep (heavily affecting the portage group, since server and client side mods fall on our head) needs to be worked out further and thus reject it. Or, you stop debating the fact portage group might have a say in this, and start discussing what needs to be done so progress is made. Balls in your court, you know we view it as unacceptable right now, if you're not willing to work with us there isn't much that can be done. ~harring pgpMPkp3ECG1U.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.
Re: [gentoo-dev] draft glep: multi-repo
On Sun, Dec 18, 2005 at 01:08:31AM +, Ciaran McCreesh wrote: > On Sat, 17 Dec 2005 17:01:59 -0800 Brian Harring <[EMAIL PROTECTED]> > wrote: > | Do you need to know how every bit of a car works to drive it? No. > > No, but I do need to know whether it has manual or automatic gears, and > where the steering wheel is. Stop spamming the list with idiot snarky responses, and discuss the issues at hand. Bluntly, others may back down from your shit but I'm not going to. A half baked proposal that is *broken* from the start being dumped on the mess that is portage is not acceptable. If you're not going to fix your glep, state so, stop wasting others time. Just take it to the council and have them ixnay it on the same issues people have continually pointed out. ~harring pgpLhEN9Gct9n.pgp Description: PGP signature
Re: [gentoo-dev] glep 42 (news) round six
On Sun, Dec 18, 2005 at 04:15:45AM +, Ciaran McCreesh wrote:
> Here we go again... Changes:
>
> * We're now supporting overlays, multiple repositories and magic flying
> chickens. To do this, we're shoving a whole load of new requirements
> onto Portage. Said requirements are documented under `Required Portage
> Enhancements`_. I now expect to get heavily flamed by a different set
> of Portage developers.
You forgot the magic mushroom badgers and snake.
> * Change to -mm-dd for GLEP 45 compatibility. Rereremove the
> timestamp on the Posted: header.
>
> * Tweak Display-If-{Profile,Installed} to work with multiple
> repositories.
>
> * Use ${repoid} rather than magic-chicken for news-*.* files.
Drop the magic-chicken crap (especially in light of your comments
about 'professional' news inline in the glep).
Killjoy maybe, but it detracts from the point of the glep.
> * Be specific on how news-repoid.skip can work.
Still haven't gotten into specifics, merely a different bit of hand
waving.
> You are encouraged to reply to this thread saying "I agree with ciaranm
> that repository IDs should not be allowed to contain spaces".
>
> TODO: ferringb wants spaces added to the first item on the list. I don't,
> because it makes repo id -> filename mappings nasty.
>
> * Every repository (including overlays) will require a unique identifier. It
> is
> assumed that an identifier will be a string consisting of characters from
> ``a`` to ``z``, ``A`` to ``Z``, ``0`` to ``9``, ``+`` (plus), ``-``
> (hyphen),
> ``:`` (colon) and ``_`` (underscore).
Not really. Just requires your code to be space safe.
You write good code, right? Especially since you need to keep our
path handling safe for osx (/volumes) and for users who do strange
things?
The news handling crap should be able to take spaces- remember the
comments about user aliasing of repostory ID's down the line. I don't
care if the actual metadata/repo_id lacks spaces, but the handling
code must be able to take spaces, as such the requirement that spaces
not be used is arbitrary and uneeded.
> * Portage must provide a way for external programs to obtain a list of all
> repository identifiers for a given system. It is assumed that this will be
> in
> the form of a ``portageq`` command (e.g. ``portageq get_repo_ids``).
>
> * Portage must provide a way for external programs to obtain the base path for
> a repository with a given ID. It is assumed that this will be in the form of
> a ``portageq`` command (e.g. ``portageq get_repo_root gentoo-x86``).
>
> * Portage must extend ``portageq has_version`` to support restrictions to a
> given repository ID.
>
> * Portage must extend ``portageq`` to implement a command which returns
> whether
> or not the profile used for a given repository ID matches a certain base
> path
> (e.g. ``portageq profile_used default-linux/sparc/sparc64/2004.3
> gentoo-x86``).
profile_in_use, maybe.
> These extensions are assumed during the following specification.
>
> News Item Identities
>
>
> Each news item will have a unique identifier. This identifier will be in the
> form ``-mm-dd-short-name``, where ```` is the year (e.g. ``2005``),
> ``mm`` is the month (``01`` through ``12``) and dd is the day of the month
> (``01`` through ``31``). The ``short-name`` is a very short name describing
> the
> news item (e.g. ``yoursql-updates``), consisting only of the characters
> ``a-z``,
> ``0-9``, ``+`` (plus), ``:`` (colon), ``-`` (hyphen) and ``_`` (underscore).
>
> News Item Directories
> -
>
> Each news item will be represented by a directory whose name is the same as
> the
> news item's identifier.
>
> The directory will contain a file named ``-mm-dd-short-name.en.txt``,
> which
> contains the text of the news item, in English, in the format described below.
>
> If a news item is translated, other files named
> ``-mm-dd-short-name.xx.txt``
> (where ``xx`` is the ISO 639 [#iso-639]_ two letter country code) will also be
> provided. However, only the English version of a news item is authoritative.
> This anglocentricity is justified by precedent [#glep-34]_.
>
> News Item Files
> ---
>
> A news item file is a text file, encoded using UTF-8 [#rfc-3629]_ for
> compatibility with and for the same reasons as existing Gentoo documentation
> [#docs-policy]_ and the tree [#glep-31]_.
>
> News items should be signed with a detached GPG signature: ::
why should vs must?
Should leaves open the possibility for a tree compromise and a news
item with Very Bad(tm) instructions stuck into it.
Moving towards getting the whole tree signed, introducing new
components that aren't required signed works against that.
> News Item Headers
> '
>
> The following headers describe the purpose and format of the news item:
>
> ``Title:``
> A short (maximum 44 characters) descriptive title. Mandatory.
>
> ``Au
Re: [gentoo-dev] glep 42 (news) round six
On Sun, Dec 18, 2005 at 06:23:55AM +, Ciaran McCreesh wrote: > On Sat, 17 Dec 2005 21:50:47 -0800 Brian Harring <[EMAIL PROTECTED]> > wrote: > | Drop the magic-chicken crap (especially in light of your comments > | about 'professional' news inline in the glep). > > Eh, there aren't any magic chickens in the glep. Intention was a nudge about keeping snarky comments out of the glep, but yep. > | Not really. Just requires your code to be space safe. > | > | You write good code, right? Especially since you need to keep our > | path handling safe for osx (/volumes) and for users who do strange > | things? > > The problem isn't my code. My code's fine. So is eselect. The problem is > people who write their own handler scripts to suit their own needs, and > then get nastily bitten because they don't realise we're allowing > spaces in filenames. People writing their own plugins/readers are responsible for what they create. They *still* need to handle space's in file paths, thus as I stated the requirement is arbitrary and uneeded. Already addressed this in irc; you provide a framework. If plugins to it suck, that's not your problem, nor is it a valid reason to constrain things just because someone might manage something stupid (remember this is gentoo, that line of logic would lock CFLAGS down to a sane set). To head off the "don't make features that are easily screwed up", this isn't one of them- this is expecting code to behave correctly from the path standpoint. Yes it's harder on bash crap, but that's also a reflection of bash (it's not an issue in python :-P ). > | > News items should be signed with a detached GPG signature: :: > | > | why should vs must? > | Should leaves open the possibility for a tree compromise and a news > | item with Very Bad(tm) instructions stuck into it. > | > | Moving towards getting the whole tree signed, introducing new > | components that aren't required signed works against that. > > I don't want to introduce any signing requirements that we don't have > already. When signing for everything else becomes mandatory, signing > for news would be too. If I make this a 'must', someone will ask me to > specify how we're handling the Gentoo keyring... Pawn the keyring off on others. The issues isn't an established trust ring, it's required signing- yes, a trust ring makes things a helluva lot easier on the user front, but it's useless without a required signing policy. We've already had this conversation also btw, in the beginning of glep42 iirc. Obviously I don't agree with your reasoning "I'll do it when it's required I do it". It's useful now, it becomes massively more useful when a trust ring is available. > | > ``Revision:`` > | > Initially 1. Incremented every time a non-trivial change is > | > made. Changes which require a re-read of the news item should > | > instead use a new news item file. Mandatory. > | > | non-trivial changes that don't require a re-read sounds like a > | contradiction. Clarify, especially since portage will mark this as > | read _once_ and only once. > > Hrm, word it as "Changes other than minor formatting tweaks", or remove > "non-trivial"? It's not a wording thing, I'm pointing out sans spelling corrections and trivial word mangling, any new info jammed in requires a new item bump so readers can display the changes. In light of that, wording above needs correction. > | This isn't incredibly useful if ranged versions are ever introduced. > | Ammending the glep for that seems stupid, looser language might be > | wise. > > What's the syntax for ranged versions? And how do they differ from SLOT > versions? >=kde-base/kde-libs-3.0 <=kde-base/kde-libs-4.0 It's not syntax as much as a boolean and of atoms. > | That's an implementation note, but I'm bringing it up since the time > | to do the filter/cache instantiation is during portage initialization > | (yes it sucks, but your stuck with stable)... so start thinking about > | ways to make it fast, since python -c'import portage' is the slowest > | part of portage queries > > Looks like I might have to do that thing in Python rather than bash > then... Do it in bash if you like being on the receiving end of atomic wedgies. > Once an hour would work fine. On the other hand, the merge is just > copying a few small files -- time-wise, it's less than generating the > cache for a couple of ebuilds. More then a couple; this beast will bloat up to hundred or so files I'd expect (remember translation serv
Re: [gentoo-dev] glep 42 (news) round six
On Sun, Dec 18, 2005 at 12:18:16PM +0200, Marius Mauch wrote: > Brian Harring wrote: > >On Sun, Dec 18, 2005 at 06:23:55AM +, Ciaran McCreesh wrote: > > > >>On Sat, 17 Dec 2005 21:50:47 -0800 Brian Harring <[EMAIL PROTECTED]> > >>| You haven't stated how the 'package manager' will trigger the user's > >>| reader of choice for these targets. Should also extend this to allow > >>| a way to disable any news notices, lest someone's cronjob get hung > >>| displaying news (feature or not, it's needed). > >> > >>The same way the package manager handles updating config files: it > >>won't. It'll just tell the user that some news items need reading. > > > > > >And you'll personally handle all of the bug spam from feature requests > >that --ask trigger $news_reader? > > > >It's a logical extension, thus people will ask for it. > > I don't think so. > How many people have asked for etc-update integration? etc-update style notices are at exit of emerge. This proposal has news item warnings prior to the merge actually occuring (no specification of sleep however). Different scenario, thus etc-update isn't a good indicator. > To quote myself: > "Granted race conditions might be an issue (where the solution > complicates tools), but that's so minor I wouldn't really care about > it." > That I wouldn't care about it isn't a general recommendation to ignore > the issue. Yes, for a perfect solution it is required, but do we aim for > a perfect solution? We do if it potentially allows for 'critical' news to be unseen, at least imo. > Another new issue nobody has mentioned yet: > The GLEP doesn't say anything about file permissions/ownership as in who > will/should be able to a) read news and b) modify the news-* files. > Without thinking too much about it I'd say a) users in portage group and > b) root. *cough* good point. ;) ~harring pgpacHFQeelTO.pgp Description: PGP signature
Re: [gentoo-dev] glep 42 (news) round six
On Sun, Dec 18, 2005 at 04:52:23PM +, Ciaran McCreesh wrote: > On Sat, 17 Dec 2005 23:27:32 -0800 Brian Harring <[EMAIL PROTECTED]> > wrote: > | To head off the "don't make features that are easily screwed up", > | this isn't one of them- this is expecting code to behave correctly > | from the path standpoint. > > Hrm, so will we be allowing spaces in package and category names too? No, due to atoms in *depend being seperated by whitespace. Wouldn't work without introducing escaping into it- beyond that the cat/pkg standard is in place already. Your repo_id however, is not, thus it's mallable. It's irrevelant either way- as I stated, your code *needs to be* space safe. Existing repo label'ing code in saviour _already_ allows spaces (it's just a fricking name), dissallowing spaces due to a concern that someone might screw up is daft. So... don't point at other things that are already set in stone and disallow spaces for their own reasons; state why it must be disallowed here, or merely state "I hate spaces". Like I said a couple of emails back, block spaces in repo_id if you like, either way the code involved has to be space safe for paths, so it's an arbitrary restriction... Dunno. Either way, path handling *must* be space safe anyways- if you restrict repo_id to lack spaces, your choice, still going to allow external aliasing of the repo_id to have spaces. > | > I don't want to introduce any signing requirements that we don't > | > have already. When signing for everything else becomes mandatory, > | > signing for news would be too. If I make this a 'must', someone > | > will ask me to specify how we're handling the Gentoo keyring... > | > | Pawn the keyring off on others. The issues isn't an established > | trust ring, it's required signing- yes, a trust ring makes things a > | helluva lot easier on the user front, but it's useless without a > | required signing policy. > | > | We've already had this conversation also btw, in the > | beginning of glep42 iirc. Obviously I don't agree > | with your reasoning "I'll do it when it's required I do it". It's > | useful now, it becomes massively more useful when a trust ring is > | available. > > Ok, how about I change it to "must", and add a note under Backwards > Compatibility along the lines of: > > At the time of writing, there is no standardised mechanism for handling > GPG signatures in Gentoo. Until such a mechanism exists, GPG signing > cannot be considered mandatory. And provisions for going back and signing everything that was _not_ signed while you delaying waiting for a keyring? That's why I'm pushing it. Mandate it as required now, keyring down the line just makes it more useful. Make it 'suggested' (which this is, you've changed nothing but words), you've left a mess that needs to be addressed when keyring comes about. Same scenario as before, think forward- force it from the get go, less crap to deal with down the line. Mandate it, no mess- just the pre-existing problem of getting a keyring collected. Delay it, keyring + going back and trying to get folk to re-sign their releases. That and any unsigned material released during that period cannot be verified, because we're waiting for a keyring. See the gains? Might be unpalatable, but it is the path of least work long term. > Ok, how's this? > > ``Revision:`` > Initially 1. Should be incremented every time a change is made to > the news item. Changes that require a re-read of the news item (for > example, most changes that are not spelling or formatting related) > should instead use a new news item. Mandatory. Works, thank you. > | > | This isn't incredibly useful if ranged versions are ever > | > | introduced. Ammending the glep for that seems stupid, looser > | > | language might be wise. > | > > | > What's the syntax for ranged versions? And how do they differ from > | > SLOT versions? > | > | >=kde-base/kde-libs-3.0 <=kde-base/kde-libs-4.0 > | > | It's not syntax as much as a boolean and of atoms. > > Hrm, ok. Wouldn't this resolve as true if you have kde-libs-2.0 and > kde-libs-5.0 installed (assuming SLOTted kde-libs)? Note I said boolean and. Resolution of that string *should* result in 3-4 via portage processing of it; doesn't handle it perfectly, but the reason I brought it up is that via limiting it to a single atom, you block (if/when) ranged versions. > | Any signed item would need to be verified also, although fortunately > | this chunk can be done in parallel to regen run. > > Hrm, is signing ver
Re: [gentoo-dev] December 15th Meeting Summary
On Mon, Dec 19, 2005 at 01:45:04PM -0500, solar wrote: > > So right now I'll go ahead and add the pycrypto code to portage, but > > will not yet add the dep to any ebuild or change anything metadata.xml > > or ChangeLog related (according to Jason 2.0.54 is still away one or > > two weeks anyway). > > If you do that please set it as a blocker for the .54 release. > Reintroducing ChangeLog/metadata.xml to Manifests would be a undesired > regression. Nothing in the portage as of <=.53 make direct use of those > two files and there is no security value in bloating the digest format > with them. Thats why they were removed 2.0.51.21 > > Making the argument for maybe portage in the future will use them is > not valid as they are currently omited and we/I have been told before > by the portage team (ferringb & jstubbs iirc??) that portage itself > wont be doing any .xml parsing in it's core. IE So that means not today > nor tomorrow will anything need to depend on those files in order to > build. Stated otherwise in irc in regards to your metadata.xml patch- metadata.xml support will be core, although due to certain constraints it'll be optional intially. At some point, we're going to have to push long desc into the cache; at that point, portage will be required to be xml aware (yay). ~harring pgpwo2Ept53wk.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Fri, Dec 23, 2005 at 10:30:09PM +0100, Carsten Lohrke wrote: > On Friday 23 December 2005 21:45, Spider (DmD Lj) wrote: > > Erm.. No, I don't think he is. We've been asking / waiting for the > > [use] syntax to appear since before you joined the project. It's been on > > "the list" for so long that many of us have given up... ; ) > > He - and I thought I just missed the thread between all those emails in my > inbox. I'm interested as well to hear a bit about the proposed enhanced > dependency syntax. dev-lang/python[tcltk] ^^^ need that atom resolved with use flag tcltk enabled >=sys-apps/portage-2.0[sandbox,!build] ^^^ need >=portage-2.0 merged with sandbox on, build off. kde-libs/kde:3 ^^^ need any kde, with slotting enabled. kde-libs/kde:3,4 ^^^ need any kde, slotting 3 or 4. Combination? Not set in stone afaik, the implementation I have sitting in saviour doesn't care about the ordering however. > > (finally we can kill use_with !! ) > > Why? There're not only autotooled configure scripts, so I don't see how to > replace it in a generic way. I don't see what this would have to do with > depending on ( ebuild foo without use flag bar ), either. assume he meant built_with_use ~harring pgpvWuwLg77mB.pgp Description: PGP signature
how to contribute to use/slot deps: was Re: [gentoo-dev] Multiple Repo Support
On Sat, Dec 24, 2005 at 12:40:35PM +0900, Jason Stubbs wrote: > On Saturday 24 December 2005 05:45, Spider (DmD Lj) wrote: > > On Sat, 2005-12-24 at 03:37 +0900, Jason Stubbs wrote: > > > On Saturday 24 December 2005 03:23, Paul de Vrieze wrote: > > > > On Friday 23 December 2005 19:12, Ciaran McCreesh wrote: > > > > > On Fri, 23 Dec 2005 18:57:44 +0100 Paul de Vrieze <[EMAIL PROTECTED]> > > > > > > > > > > | Do those already work then? I'd like to be able to use them. > > > > > > > > > > Not in anything end users should be using. The syntax is pretty much > > > > > decided upon though... > > > > > > > > Glad that they are comming though. Even though I'd probably not hold my > > > > breath. > > > > > > Trolling? > > > > Erm.. No, I don't think he is. We've been asking / waiting for the > > [use] syntax to appear since before you joined the project. It's been on > > "the list" for so long that many of us have given up... ; ) > > Yep, bug 2272. (still was trolling). > > I don't think its trolling when we've been let down on it in the past, > > had it postponed to "the great redesign" ( project baghira, I think, > > too) And so on. > > "Even though I'd probably not hold my breath"? It's something that many > people > want but most are not evening willing to attempt implementing it. What was > the purpose of that comment? Expanding on this since jason's email is quite a bit nicer then my original response. Frankly... the potshot at portage is mild bullshit, but at this point I'm getting accustomed to it- bit easier to take a swipe at portage rather then to do actual work improving things (low blow potentially, but it sure as hell seems to be the case). If folks are looking to get this feature, here's how you scratch that itch. 1) design and implement your own stable based patch that is maintainable. 2) help complete the saviour branch which holds a massive refactoring (including use/slot required refactoring). Use/Slot is already sitting in that branch btw, although the resolver handling of it (ability to dig itself out of use cycles) isn't there yet. 3) help with the day to day bug mangling, regression fixes, and general maintenance. Or work on the small features that need to be dealt with; either way, help reduce the load so existing portage devs can implement the beast. Note that nowhere in that list, is nagging/snarky comments/general asshattery on public ml's listed as a means to get what you want. That's actually something of a negative contribution, since time is spent sending pissy emails such as this, or just results in people saying "screw portage work". Devs making noise, you know what the scenario is, you're on the receiving end of it too for your area of work. Portage is no different. It's really pretty simple- get off your butt and chip in if you want it, else you're on _our_ timeline (eg, we implement it when we deem it sane/ready to go). It's been 3 years for the bug- more then ample time to have contributed for some of the devs complaining in this thread. Chip in, or bite your tongue essentially. ~harring pgp8Y001vliBX.pgp Description: PGP signature
Re: how to contribute to use/slot deps: was Re: [gentoo-dev] Multiple Repo Support
On Sat, Dec 24, 2005 at 05:33:06PM +, Ciaran McCreesh wrote: > On Fri, 23 Dec 2005 23:56:37 -0800 Brian Harring <[EMAIL PROTECTED]> > wrote: > | It's really pretty simple- get off your butt and chip in if you want > | it, else you're on _our_ timeline (eg, we implement it when we deem > | it sane/ready to go). > > Is Portage development done to support the needs of those of us who > provide the tree, or is the tree expected to be restricted to whatever > Portage developers feel like implementing? Personally, I'd state anyone who thinks we're implementing only what we find fun to do is trolling something fierce, but I'm also a portage dev thus my views are a bit different. Regardless, ciaran's own statement via irc "that the portage devs are hurting gentoo by ignoring certain requests" still harkens right back to my point- if you believe it to be the case, nagging/bitching ain't going to improve it in anyway. People, you've got the source. You want it and think we're moving to slow/being tools/incompetent jackasses, whatever the belief, _you_ can do something about it that results in actual progress- I already stated the ways to help in my last email. So... again, you want it, help, or kindly sit back and wait for it to be implemented on our timeline. ~harring pgpcnzm3uK1lH.pgp Description: PGP signature
Re: [gentoo-dev] mac/xmms-mac licence issue
License in question... http://bugs.gentoo.org/attachment.cgi?id=35862&action=view On Sat, Dec 24, 2005 at 06:11:53PM -0800, Bret Towe wrote: > earily today i updated the ebuilds for mac and xmms-mac, > for those that dont know their applications for monkey's audio (.ape files), > and got them submited to bug 94477[1] which was closed > due to the way the licence was done Original license really sucks... doesn't matter if someone has grabbed the code and labeled it lgpl2, it still is under the monkey license. > my issue is i think the ebuilds should be commited to portage > as i dont see how the licence or issues that app has anything todo > with a gentoo ebuild as all the ebuild does is fetch and install > and its only told todo so upon the user requesting it to be so > hence its the users choice to deal with the licence rather than > the developers desiding for that user We're not deciding what licenses users should use (despite pushes from both extremes looking to enforce their license view on others). That said, it's not actually the issue at hand. Issue at hand is violating someone else's license (clarified below). > i can understand putting proper warning in the ebuild if the dev > thinks that its worth the user really noting the issues surrounding > it, not forcing their ideals onto the user > if i wanted that i would run debian See above, and drop the rhetoric please. > > for those that havent figured it out yet from reading the above > i dont care the politics of the issue with the licence all i want > is the functionality of the ebuild concerned Politics do suck. That said, lawyers crawling up your ass sucks worse. Bluntly, you're asking a collection of devs, who have their own contributions protected by licenses, to ignore a source base's license. That's going to be one hard sell. ;) > if it is the case that the devs believe the user is totally incapable > of making choices for themselfs then i suggest putting up > somewhere noting it as such Again, ixnay rhetoric; if we violate the license (which we would be doing), we're responsible (along with user who uses it). It doesn't matter if someone else has picked up the source and labeled it as lgpl, unless the new project has *express* permission from the original author, they're not even allowed to screw with the source- the new project could be viewed as a new program. Barring the new program angle, there still is the requirement all fixes/changes be contributed back to the original upstream. Original upsream being dead means it's effectively impossible to improve the source. This is why the original license is a major issue. Effectively, the codebase cannot be improved/fixed without the original author, due to restrictions keeping the code bound to him/her. If he/she goes mia, the project is dead developmentally due to the restrictions, which makes putting the package into portage an even harder sell. Jakub responded in this thread about shipping a crap license... imo, that's not the issue. The issue is that we would be knowingly violating a license (however horrid the license is). Two routes out of this- clean room reimplementation of the codec, or someone manages to track down the original author and gets the code converted to a different license. Latter still is tricky, since any contributions to the project, you would need all authors to sign off on the new license- this is assuming the project doesn't do centralized copyright, and assuming people have actually contributed to it beyond original author. ~harring pgpDVL65jFm29.pgp Description: PGP signature
Re: [gentoo-dev] mac/xmms-mac licence issue
On Sat, Dec 24, 2005 at 07:17:05PM -0800, Bret Towe wrote: > On 12/24/05, Carsten Lohrke <[EMAIL PROTECTED]> wrote: > > This isn't politics, but copyright infringement on top of a ridiculous > > license > > (when you want to see it as one) we had a short discussion¹ about several > > months ago. > > im sorry i fail to see how copyright infringement or a ridiculous licence > matters when commiting a ebuild to portage just pick a licence if thats the > issue warn the user and leave it at that The new package uses the source of the original; we knowingly package/ship that, we're infringing on the copyright. Say I commit it, and the original author comes back with an army of lawers. They sue my ass, and whoever they can think of (money is a wonderful thing, no?). That's why it matters. We get nailed, users too can get nailed. Re-read my email. If I didn't make it clear, I'll try and clarify it- the new package is *knowingly* violating the license, and we've already got enough info sitting in bugs.g.o that it's documented we would knowingly be violating the license if we went forward with it. Hell, if the new package has modified the original source in anyway, it's already in violation of the license for not contributing the changes upstream. Either way, it's not going to happen without one of the 2 routes I mentioned in my previous email occuring. Yes, it would be nice having it in the tree, but the original author really shot themselves in the foot via the license they choose- we're stuck operating within those confines, thus we're boned (as are users). ~harring pgpnmT0bncekn.pgp Description: PGP signature
Re: [gentoo-dev] mac/xmms-mac licence issue
On Sat, Dec 24, 2005 at 07:22:50PM -0800, Bret Towe wrote: > > > i can understand putting proper warning in the ebuild if the dev > > > thinks that its worth the user really noting the issues surrounding > > > it, not forcing their ideals onto the user > > > if i wanted that i would run debian > > > > See above, and drop the rhetoric please. > > im sorry for attempting to get my idea across Nothing wrong with discussion- you're pushing a contraversial idea. Don't need rhetoric to get what you want, you need *facts* and *good* arguements as to why your way is right. Rhetoric doesn't fall under that, since someone will see through it and the bs flaming will start up shortly after- thus it should be avoided (and yes, I'm sure I'm probably being a hypocrit here). > > > for those that havent figured it out yet from reading the above > > > i dont care the politics of the issue with the licence all i want > > > is the functionality of the ebuild concerned > > > > Politics do suck. > > > > That said, lawyers crawling up your ass sucks worse. > > > > Bluntly, you're asking a collection of devs, who have their own > > contributions protected by licenses, to ignore a source base's > > license. That's going to be one hard sell. ;) > > > > i thought i was asking how commiting this can even affect the devs > or gentoo in general Again, you're asking us to take part in license violation- depending on the lawyerly interpretation of the license, either we're actually in violation of the license, or we're enabling license violation. Already made it clear in the previous email, you're asking folks who have their hard work protected by licenses to knowingly violate a license. Ain't going to hapen. > > > if it is the case that the devs believe the user is totally incapable > > > of making choices for themselfs then i suggest putting up > > > somewhere noting it as such > > > > Again, ixnay rhetoric; if we violate the license (which we would be > > doing), we're responsible (along with user who uses it). > > how does that work? an ebuild is a script or do you mean by the dev > testing it they also perform the same action as the user would? See above. > > It doesn't matter if someone else has picked up the source and labeled > > it as lgpl, unless the new project has *express* permission from the > > original author, they're not even allowed to screw with the source- > > the new project could be viewed as a new program. > > > > Barring the new program angle, there still is the requirement all > > fixes/changes be contributed back to the original upstream. > > > > Original upsream being dead means it's effectively impossible to > > improve the source. > > orignal doesnt matter as long as someone is Original matters, because the new project is using that codebase- they're bound by the license of the original regardless of whether or not they abide by it (iow, regardless of if they're violating the law or not). > and again i am sorry if i seem to repeat myself a bit but i find > people i talk to ether dont get what im talking about or dont listen > so i end up going in circles trying to beat what im saying into their head *Cough* there is the possibility that folks who do packaging of software might have a clue on the licensing issues here, and be seeing something you aren't :) Yes it's arrogant/elitist, but my point is that our differing opinion might have valid logic behind it. Basically... don't talk _at_ people, talk and listen (discourse). ~harring pgpDxHdQYp9QL.pgp Description: PGP signature
[gentoo-dev] $BUILDDIR in ebuilds
Hola all. Just sending a notice/reminder that ebuilds should not be using $BUILDDIR directly- especially since vapier just commited a rename of that var. ~harring pgpunxuTIS1nk.pgp Description: PGP signature
Re: [gentoo-dev] Re: $BUILDDIR in ebuilds
On Mon, Dec 26, 2005 at 02:51:26AM -0500, Michael Sterrett -Mr. Bones.- wrote:
> Like in here?
>
> app-doc/halibut/halibut-0.9.ebuild: BUILDDIR="${S}/build" \
> net-dns/maradns/maradns-1.0.27.ebuild:BUILDDIR=${S}/build \
> net-dns/maradns/maradns-1.0.32.ebuild:BUILDDIR=${S}/build \
Actually, calls of that sort is why it's being changed.
They're not relying on portage supplied BUILDDIR location, they're
defining it as an arg to make- the problem is that portage supplied
BUILDDIR has the potential to get used by make.
Either way, those 3 are fine- they're not relying on portage provided
BUILDDIR var, just issueing a directive to make.
~harring
pgpdWcjktb4hS.pgp
Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tue, Dec 27, 2005 at 12:46:49AM +, Ciaran McCreesh wrote: > | > The existing syntax is just as extensible. Up the EABI revision, and > | > start adding new syntax as needed. > | > | EAPI has nothing to do with the consistency of the syntax. Getting it > | once right, is what you usually call for. I prefer clean data > | structures. > > The proposed syntax is cleaner than shoving arbitrary stuff inside > [bleh]. Any new [role:] tags will require an EABI bump anyway, so > there's no reason to stick to your proposed syntax to avoid future > backwards compatibility breaks. Expanding a bit... Via eapi, if we wanted to throw out the syntax down the line we could. Not saying it's a great idea, but EAPI exists to provide immediate transition to incompatible changes instead of the usual "work out a semi backwards compatible way, don't use it for 6 months, then deal with the bugs". ~harring pgp1G7nGB2yqm.pgp Description: PGP signature
Re: [gentoo-dev] Allow upstream tags in metadata.xml (GLEP 46)
On Tue, Dec 27, 2005 at 12:59:34AM +, Ciaran McCreesh wrote: > On Tue, 27 Dec 2005 01:45:00 +0100 Stefan Schweizer > <[EMAIL PROTECTED]> wrote: > | That will increase the sync time for all of our users - can we please > | keep this info out of the sync-tree? > > Learn to use the rsync exclude list. metadata.xml is/will be required someday due to long description being stuck in there. Excluding it isn't incredibly useful in light of that. Personally... would rather see maintainer info stuck somewhere else, but not something I'm going to fight tooth and nail over. ~harring pgpopukAAH02V.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tue, Dec 27, 2005 at 01:03:49AM +, Ciaran McCreesh wrote: > On Mon, 26 Dec 2005 16:57:07 -0800 Brian Harring <[EMAIL PROTECTED]> > wrote: > | Not saying it's a great idea, but EAPI exists to provide immediate > | transition to incompatible changes instead of the usual "work out a > | semi backwards compatible way, don't use it for 6 months, then deal > | with the bugs". > > Addition of any new dependency filtering criterion is a backwards > incompatible change anyway. If you add, say, [fish:trout] and older > versions of Portage don't recognise [fish:], there's no way for said > older Portage versions to know what to do. Being able to parse > additional DEPEND constructs is not sufficient. Guessing you're missing how EAPI works. The scenario you're pointing at isn't an issue for EAPI aware portage versions. If portage doesn't know of that EAPI version, it flat out won't do _any_ operations on that package; it's filtered out of available packages. Hell, we don't even store the metadata in the cache- the reasoning being that if we don't know of that EAPI version, there is _no_ gurantee we'll even be processing the metadata dumped from ebuild.sh properly (nor that ebuild.sh will produce proper metadata for that eapi). So... for scenario above, portage sees the differing EAPI, masks the package on it's own- the new dependency format isn't seen, nor processed by portage. Like I said, via EAPI we can effectively break whatever we want format wise, do a total quick cut over without breaking older eapi aware portages (this is the reason eapi exists). Non eapi aware portage's will be boned, but so it goes. They're going to be progressively more screwed the further we go portage wise anyways, so it's something of a lost cause (imo). ~harring pgp73LMMl2yGl.pgp Description: PGP signature
Re: [gentoo-dev] Allow upstream tags in metadata.xml (GLEP 46)
On Mon, Dec 26, 2005 at 08:12:03PM -0500, Dan Meltzer wrote: > On 12/26/05, Lares Moreau <[EMAIL PROTECTED]> wrote: > > On Tue, 2005-12-27 at 00:59 +, Ciaran McCreesh wrote: > > > On Tue, 27 Dec 2005 01:45:00 +0100 Stefan Schweizer > > > <[EMAIL PROTECTED]> wrote: > > > | That will increase the sync time for all of our users - can we please > > > | keep this info out of the sync-tree? > > > > > > Learn to use the rsync exclude list. > > > > > I think the point was that the 'average' user needs to pull it as well > > and has _no_ use for it. > > > > There are already complaints about syncs taking to long. > > The complaints was about the cache, not about the actual sync time Complaints about both actually- try sync'ing on a crap connection. Rsync doesn't scale well the larger the dataset gets (the fact it still performs well is a testament to it being mostly a damn fine tool). We've got at least a 2.4mB overhead just for doing filelist/chksum transfers; that's not getting into pulling the _actual_ updates. > This is what, maybe the equivilent of a new ebuild once, and a -rX any > time somethings changed? It won't effect much at all and end up being > a lot more helpful (and quickly implemented) than waiting around for > someone to write a web database and pushing that through. Quicker balanced against proper; debate right now is if it's the proper place to do this (thus address that concern) :) > We have metadata.xml's, why not use them? We have ebuilds, why don't we stick it there? Arguement doesn't work well there ;) (No I'm not advocating tagging this into ebuilds btw). ~harring pgph86K44E7lU.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Mon, Dec 26, 2005 at 09:09:31PM +0100, Carsten Lohrke wrote: > On Saturday 24 December 2005 02:04, Brian Harring wrote: > > dev-lang/python[tcltk] > > ^^^ need that atom resolved with use flag tcltk enabled > > I think that's exactly what someone told me months ago. :) > > > >=sys-apps/portage-2.0[sandbox,!build] > > > > ^^^ need >=portage-2.0 merged with sandbox on, build off. > > I wonder if portage deals fine with subtle dependency incompatibilities, when > one package has foo[!bar] and another one foo[bar] as dependency and spits > out a reasonable error message to apply mutual blockers. Actually, you just hit upon one of the main reasons use/slot deps have taken so damn long. Jason can state it better, but our resolver basically chooses a single path when doing the resolution; if that resolution turns out to be an issue during later resolution steps, existing resolver doesn't back track and choose a different (valid) path. Note the up/down cycling bugs. Guess how that comes about? use/slot deps is a combination of depset extension (plus any code that deals with depset), and resolver extension so it handles the extension of depset properly- namely, getting issues from above handled, trying to dig it's way out of use cycles that aren't hard deps, etc. So... basically, your concern is with the resolver, not use/slot deps syntax. > > kde-libs/kde:3 > > ^^^ need any kde, with slotting enabled. > > > > kde-libs/kde:3,4 > > ^^^ need any kde, slotting 3 or 4. > > > > Combination? Not set in stone afaik, the implementation I have > > sitting in saviour doesn't care about the ordering however. > > This is the one I'm entirely not sure what it is good for. To me it looks > more > like a workaround for missing dependency ranges, but it won't solve any issue > for KDE related packages. What are dep ranges? It's the intersection of any version set's specified by common cat/pkgs. In other words, instead of just processing atom by atom, grab the depends, collapse them down into cp->version restrictions, _then_ do the search. The issue you're pointing at isn't use/slot dep based, it's resolver based (again). ;) > - The dependencies we have are always >=kde-libs/kde-x.y and when KDE 4 is > due, we can change to =kde-libs/kde-3.5* because everything else won't be > supported anymore. So unless I miss something, kde-libs/kde:X is superfluous. Missing something /me thinks. shouldn't really be specifying >=kde-x.y; should be specifying the slotting. Do that, and you wouldn't have to go back and change it over to =kde-libs/kde-3.5* ; you just mark the new kde-4 as a different slot. Basically... it's how it *should* be done from the get go, rather then going back and fixing things via tweaking the scary eclass y'all have. :) > As a general remark I'd like to know if and how this enhanced dependency > syntax is ordered. :[], []: or is both allowed!? What if we find out, that we > need to consider another factor, later? :[]<>? Like I stated in a previous email, the ordering isn't specified- right now we can split upon [] matches to handle it regardless of ordering, although I'd think some form of ordering would be wise... ~harring pgpQWMlk6YWcl.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tue, Dec 27, 2005 at 02:31:02AM +0100, Carsten Lohrke wrote: > On Tuesday 27 December 2005 01:46, Ciaran McCreesh wrote: > > You solve this either by SLOTting bar and making each bar SLOT use a > > SLOT dep upon KDE, or by using USE flags and [use]:slot deps. > > It's not a that uncommon case and would lead to dozens, very likely > (depending > on the future development of KDE and libs around it) hundreds of duplicated > ebuilds. In short: Your approach would result in a unmaintainable mess and is > not going to become reality. Well, we all seem to be missing the issue, so please spell it out clearly (rather then "it's going to get bad"). Didn't grok it from the previous email, so spell it out please :) ~harring pgpuspkYXF34v.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tue, Dec 27, 2005 at 03:01:13AM +0100, Carsten Lohrke wrote: > On Tuesday 27 December 2005 02:29, Brian Harring wrote: > > So... basically, your concern is with the resolver, not use/slot deps > > syntax. > > I did not say that this would have anything to do with the syntax. Am I right > to extract from your words that we get rid of ~arch users complains about > up/downgrade cycles with Portage 2.1 as well, but have them confronted with a > proper error message!? :) Never said anything about 2.1 + resolver enhancements (no clue where that one came from). Merely commenting on your raised issues about use/slot deps. > > > - The dependencies we have are always >=kde-libs/kde-x.y and when KDE 4 > > > is due, we can change to =kde-libs/kde-3.5* because everything else won't > > > be supported anymore. So unless I miss something, kde-libs/kde:X is > > > superfluous. > > > > Missing something /me thinks. > > shouldn't really be specifying >=kde-x.y; should be specifying the > > slotting. Do that, and you wouldn't have to go back and change it > > over to =kde-libs/kde-3.5* ; you just mark the new kde-4 as a > > different slot. > > Of course slot dependencies are cleaner. Just that they don't address a > practical problem with ebuilds buildable against multiple slotted ebuilds of > one packages, but the need to have them, their dependencies and all other > ebuilds depending on the latter (ones [sp?]) built against one and the same > ebuild ( In reality a set of ebuilds, named KDE X.Y). That sounds more like a failure of the ebuild's dep/rdep specification, either that or your hinting at the need to lock down the rdep's an ebuild was built against. Either way, still not totally following your complaint, thus an actual example would help (easiest to assume I'm a moron, and start at that level of explanation). ~harring pgpQ2ALMkuOU4.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tue, Dec 27, 2005 at 03:07:52AM +0100, Carsten Lohrke wrote: > On Tuesday 27 December 2005 02:23, Ciaran McCreesh wrote: > > Nooo! That's exactly the point I was making. Carsten is assuming that > > by using [slot:bar] syntax, no backwards incompatibility will be > > introduced by adding a new [fish:] key. > > Nooo! ;) I said it would look more consistent, than always adding a new way > (§$%&€<> or so) to describe or latest enhanced dependency atom. Either way, it's going to require depset extension, and an EAPI bump. I'd rather deal with it as it comes rather then trying to jam everything into it now. EAPI allows us to do whatever we want once portage aware versions are deployed- I'd rather abuse that then make a mess of use/slot for syntax I personally dislike. :) ~harring pgp2NtLa1e2Zu.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tue, Dec 27, 2005 at 03:32:04AM +0100, Carsten Lohrke wrote: > On Tuesday 27 December 2005 03:11, Brian Harring wrote: > > Either way, still not totally following your complaint, thus an actual > > example would help (easiest to assume I'm a moron, and start at that > > level of explanation). > > O.k. > > 1. You have KDE 3.4 and Digikam (version doesn't matter) installed > 2. You update to KDE 3.5 > > What you now have is the following: KDE 3.5 works fine and Digikam as well, > just that it uses KDE 3.4 libs. But what happens: A Digikam update (or you > rebuild for whatever reason). You emerge it (against KDE 3.5), but its > dependencies (libkipi, libkexif ) are still built against kdelibs 3.4. The > result is that compiling Digikam fails. You need to rebuild these > dependencies and every other ebuild depending n those against KDE 3.5. And > Portage should do that transparently. > > For now I have written slot_rebuild() which detects the problem at least and > provides the user with the information what to do, but it's dead ugly. The version of digikam being merged requires slot=3.5- it should be depending on libk* slot=3.5, also, no? As long as the information is represented dependency wise, portage should be able to handle it fine. Just need to have that info there. If an ebuild dep/rdeps via || (), then we're getting into whether or not portage should be filtering || () down to the selected atom... ~harring pgpxKb6IUuH0e.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tue, Dec 27, 2005 at 03:36:00AM +0100, Carsten Lohrke wrote: > On Tuesday 27 December 2005 03:11, Brian Harring wrote: > > Never said anything about 2.1 + resolver enhancements (no clue where > > that one came from). Merely commenting on your raised issues about > > use/slot deps. > > From your words. Thanks for destroying my hope in two sentences. ;p > So we add this dependency enhancement without having a Portage version in > place that can resolve issues as they appeare!?! Scary. Who said anything about this going into portage _without_ the resolver enhancements? Re-read my emails, I've stated the resolver improvements are *required* for use/slot to go in (specifically use). So... yeah, you're not following what I've been saying. ~harring pgpc9KHL8TcON.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tue, Dec 27, 2005 at 03:54:38AM +0100, Carsten Lohrke wrote: > On Tuesday 27 December 2005 03:40, Brian Harring wrote: > > The version of digikam being merged requires slot=3.5- it should be > > depending on libk* slot=3.5, also, no? > > No! It (and also its dependencies) can be built against each 3.x slot. > > > As long as the information is represented dependency wise, portage > > should be able to handle it fine. Just need to have that info there. > > It can't be handled dependency wise, because what is interesting is against > which KDE version the relevant ebuilds are actually installed. So note the comment in the email you are responding to about locking down the used dep/rdeps for an install. Via that, could lock down the slot it was compiled against. Bit more to it then that, but the concerns your raising *again* are not use/slot based, your pointing at other portage faults (thus please seperate those concerns from use/slot). ~harring pgpCRl3G2aOe0.pgp Description: PGP signature
Re: [gentoo-dev] Stupid USE defaults that need cleaning
On Mon, Dec 26, 2005 at 11:28:17PM -0500, Chandler Carruth wrote: > It occurs to me that this could be (to an extent) accomplished by having > a few more "specialized" subprofiles for x86: base, desktop, gnome, and kde. > > base - as the name implies, a _basic_ starting point... very similar to > server profiles, etc. veeery minimal. > desktop - almost identical to the current USE flags -- what Joe Q. User > "should" have to be safe, and have programs function as expected. > gnome / kde - slight specializations of the above to tailor the use > flags for one desktop environ or the other.. > > Problems? > 1) heavier usage and depth of the profile, making where things come in > more and more obscure. > 2) could lead to proliferation of environment tailored "desktop" > derivatives. (xfce, fluxbox, the list could go on) This may not be a > problem as many distros have successfully divided between KDE and Gnome, > and the base / desktop profiles would allow users ways to customize, as > always. > 3) there is _no_ functionality added by any of this, only > "user-friendliness" after a fashion, and as such, perhaps it should all > be chucked in favor of having users competently declare their own global > USE flags during the install, however I doubt that'll get very far. *shrug* 4) need for the ability to inherit multiple parent profiles. Otherwise, x86 desktop profile is not guranteed in anyway to reflect sparc desktop profile (yes, somewhat the case now). A gnome desktop profile would make sense imo, but from a work standpoint is totally dependant on ability to inherit multiple parents. ~harring pgp4ylbEVAr9i.pgp Description: PGP signature
Re: [gentoo-dev] Stupid USE defaults that need cleaning
On Tue, Dec 27, 2005 at 12:10:04AM -0500, Chandler Carruth wrote: > Brian Harring wrote: > > >On Mon, Dec 26, 2005 at 11:28:17PM -0500, Chandler Carruth wrote: > >>3) there is _no_ functionality added by any of this, only > >>"user-friendliness" after a fashion, and as such, perhaps it should all > >>be chucked in favor of having users competently declare their own global > >>USE flags during the install, however I doubt that'll get very far. *shrug* You're ignoring the ability to specify additions to the system set; use flags aren't going to help there. > >4) need for the ability to inherit multiple parent profiles. > > > >Otherwise, x86 desktop profile is not guranteed in anyway to reflect > >sparc desktop profile (yes, somewhat the case now). > > > >A gnome desktop profile would make sense imo, but from a work > >standpoint is totally dependant on ability to inherit multiple > >parents. > > > How close is that ability to portage? Is there interest/room for > help/work towards it? 30 minute patch if people want it (line 999 of portage.py from trunk is the area of modification required). Due to current code, would need to either educate users, or come up with some way to make existing code puke when working with N parents- right now the code automatically ignores any other entries in the parent file (ba design choice). > I would like to see a more sensible approach to > establishing default settings (USE flags not the only thing here). IUSE defaults; specifying the use defaults within the ebuild itself (search the -dev archives for it, spanky brought it to the ml iirc). IUSE defaults is not a 30 minute patch. ~harring pgpzBve7MaQJ8.pgp Description: PGP signature
Re: [gentoo-dev] Re: Installing COPYING or LICENSE files
On Tue, Dec 27, 2005 at 02:08:25AM -0500, Mike Frysinger wrote: > On Tuesday 27 December 2005 02:01, R Hill wrote: > > AFAIK most licenses need to be included with the distribution of the > > source, not installed on the system after compilation. But I could be > > wrong too. > > anyone who installs a program in portage already has a copy of the license on > their system ... $PORTDIR/licenses/ Assuming the tree is locally available (remote, or binpkg's used to generate images)... Lets put it this way; if ebuilds are specifically filtering it out on their own, nobody who wants the licenses install has them. If they're installed via the ebuild, and removed via INSTALL_MASK, everybody can get what they want. So why nuke by default? ~harring pgpFZGuIgYNZb.pgp Description: PGP signature
Re: [gentoo-dev] ChangeLogs and rsync time
On Sun, Jan 01, 2006 at 10:48:18PM +0100, Grobian wrote: > On 01-01-2006 21:35:34 +0100, Francesco Riosa wrote with possible deletions: > > 1) bzip2 them in some way. > 4) compress Changelog entries where possible Anyone gathered transfer stats for rsync without --whole-file? compression won't play nice with rsync's delta compression... ~harring pgpYKSYtHmDuY.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
On Wed, Jan 04, 2006 at 10:05:52PM -0800, Corey Shields wrote: > Where is the centralized vision that everyone is working together here that > people not directly related to each project will buy in to and therefore do > what they can to see it succeed? We've had centralized visions for a long while. Recall use/slot deps? See them available anywhere? Vision ofr an installer? Yes, underway now, but the centralized vision really didn't do jack for actually acquring folk to work on it, did it (feel free to chime in agaffney since it's effectively yours now a days). > Where is the collaboration between groups > to make it happen? How many projects actually require collaboration amongst multiple groups to pull it off? Yes, if it's infra related we're stuck waiting on you guys to move, but where else is the intricate dependencies between groups y'all seem to be seeing? Don't get me wrong, there *are* dependencies between groups (everyone reliant on toolchain fex). What I'm getting at is that the angle of blaming communication for lack of progress is daft- the issue isn't lack of communication, it's lack of _actual_ work being done. > Portage team is running in one direction, > webapps another, GLI a third direction (while kicking anyone who wishes to > run with them in the nuts). Examples would be lovely. > In any structured environment I have worked in, > you have a heirarchy where everyone, down to the grunts, know where they are > heading as an organization, why they are heading that way, and what they can > do to help. Even though groups work on differing things, they know how those > things are directly affecting the end goal (mission statement, whatever) > > Right now, Gentoo has it's cliques that come up with their own things, and to > get assistance from another clique you're gonna have to have some ties or > work real hard to sell your idea to them. It's too flat of a model to work > for any real innovation, else, as Kurt pointed out, we would have seen some > cool stuff in the past couple of years. > > > If this Gentoo project fails/falters (like you seem to think it is > > heading) you are free to do the same, form your own project with it's > > own set of rules and leader if you so choose. > > Gentoo won't fail.. I don't believe that is what Kurt or Lance are saying. > I > think the point was that Gentoo is not moving at the typical pace of OSS > development, and we believe that it is the organizational structure that is > holding it back. Actually, here's where I'm going to get lynched- (both for bringing up anon* after pissing y'all off by asking about it less then 24 hours previously, and stepping on other toes). Typical foss project is optimized for one thing, and one thing alone- maximal usage of available resources. It has to be *easy* for folks to contribute whatever time they have- this means eliminating as much menial/manual work as possible. Immediate access to most current source so they can raid it and patch it, rather then splitting against an old version, then the maintainer forward porting the patch to head fex is a huge issue. It wastes both the maintainer's time and the random patch submitters time having to juggle between revisions. Further, foss has something of a rapid release cycle. We're actively trying to move in the opposite direction if you consider the actual implication of trying to widen the unstable keywording gap- I'm not stating QA is bad, what I'm stating is that QA explicitly requires delays built in (whether via multiple reviews by devs, or letting the changes sit for a while). End result of it is that it takes longer to get stuff out, with the result waterfalling across the tree- cool nifty package x that has bleeding edge dep y, with dep y sitting due to QA concerns for example. I've not yet actually touched on communication/sync'ing up between volunteers either- that's further delays. For example, you've got crazy/nifty feature X that must be glep'd. You've got realistically a wait of a month before it's worth starting the actual work for it. Yes, a month. Reason being that glep can be ixnayed, thus those with half a brain aren't going to do work that could be shot down, they're likely going to wait till the proposal is accepted *then* start the work. Probably pissing a selection of people off here (pardon, deal), but the point is that this notion that introducing more communication/sync up points isn't going to accomplish anything. Yes, it's required, but foss is not your typical business work place (thank god). Why has gentoo gotten slower as it's gotten larger? Because the lone wolf developer has less bullshit to deal with, they can just hammer towards their goal. Introduce more folk into it, waste more of their time syncing up with each other, more time of those who see their goal, know how to get their, having to run it past everyone who wants to be know what's afoo
Re: [gentoo-dev] Thoughts on the whole gentoo future discussion
On Thu, Jan 05, 2006 at 10:00:08AM -0800, Matthew Marlowe wrote: > Hi all, > > The following are just my opinions/summaries: > > 1) It appears that the most dissatisfied devs are those > who have been proponents of the "enterprise" aspect > of gentoo. When they say that not much has been > accomplished in the last 2 years, I think you have to > look at it from the enterprise point of view. GLEP19 > never got anywhere. Other than small improvements, > I'm not sure anything positive has happened. If anything, > Gentoo appears to be heading more in the "desktop" > and "hobbyist" direction. That might be what they mean > when they say gentoo is becoming irrelevant. > > cool stuff happening in gentoo on the hobbyist and desktop > side. Where is the effort to actually make glep19 a reality? I've sniffed around from the portage side of things, and personally I've not seen any actual work done towards it. Same thing with a 'central vision' provided notion of parallel-fetching- wasn't implemented till someone who was annoyed enough, got off their ass and implemented it. If it wasn't clear from my badly worded previous email, effectively, you want it, get off your butt and get it. No free lunches unless you're lucky enough to have someone willing to do the work for you. Not stating that each group is going to do only what ever they deem (although frankly, some groups seem to operate close to this), but I *am* pointing out that all of the issues with ent. gent., I've not seen anyone actually work on them. See my point? Glep19 went no where because it was a proposal (seemingly) without any actual work done on it. Of course it's going to stall out, proposals do not translate to code without resources (manpower) to make it a reality. > Therefore, I think the devs who favor the desktop stuff > just really arent understanding how the enterprise devs > have been disillusioned here. See above. I stopped poking about glep19 due to the fact nobody seemed to actually be doing anything. Reiterating it so it's absolutely clear, reality is that those who want it have to do the work. Hell, it's stated in the glep process. Yes, ent.gent. would be nice, but I'm more inclined to work on portage then on specializing the tree/snapshott'ing process for others when they haven't even started the basic work required (nor is the proposal even particularly finished/fleshed out). Maybe if the core of glep19 were actually fleshed out in the glep, and the _basic_ initial work was finished I'd have an interest, but right now I (bluntly) don't care enough about a special interest to jump in and effectively spear head their own proposal. Note also that I'm picking at glep19 here; I'm not picking at efforts to stabilize the tree nor introduction of ent. features into gentoo. Merely pointing out the core of ent. gent. must be glep19, yet those who want it aren't doing anything to achieve it. > 2) Although the "future discussion" doesnt seem to be bringing > devs any closer together, I saw at least a few decent suggestions > that we should follow up on. > >- Have a planned annual developers conference >I think this is critical, I would be willing to help with the > implementation >if it gets the green light. > > - Consider the possibility of eventually redefining gentoo entirely as a > metadistribution >and have devs more formerly broken up into different teams of > enterprise, desktop, etc >devs where the eventual product might be seperate trees or release > media for each >team. See my previous email about what 'redefinitions' and 'refocusing' and 'specialization of interests' will actually accomplish. People organize on their own, sometimes badly, sometimes better then any management overhead could achieve. Either way, the possibility you state doesn't provide any backing for a reason to do so, thus I wonder what it actually would accomplish :) ~harring pgpPFuWGGS1uZ.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 42 (news) Round Seven
On Thu, Jan 05, 2006 at 03:11:38PM +, Ciaran McCreesh wrote: > Nerry there now... Changes: > > * Due to overwhelming demand (it's the thing in this GLEP that has > generated least contention!), spaces are not allowed in repository > names. +1 on this revision, although I demand a pony. ~harring pgpaoH8casuGP.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 19: Gentoo Stable Portage Tree -- ideas
On Thu, Jan 05, 2006 at 11:52:22PM -0500, Andrew Muraco wrote: > noticed something that doesn't make any sense: > > Andrew Muraco wrote: > > >- the existing portage code would consider +arch as a subset of arch, > >the reason both keywords will exist is to maintain compatibility with > >older versions of portage which will not recognize this. > > would make more sense as: > > >- portage should consider +arch as a subset of arch, however, the > >reason both keywords will exist is to maintain compatibility with > >older versions of portage, which will not recognize this new keyword. glep19 isn't going to become a reality in the next 3 months, so the backwards compatibility constraints for keywords isn't an issue. If people got this ironed out, any required keyword/metadata mods can just be slipped in via eapi (this is assuming the mods are sane and agreed upon by all, also). And yes, I'm going to *love* abusing the hell out eapi once the waiting period is up. Useful for fun stuff like this ;) ~harring pgppbvJooXJSS.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 19: Gentoo Stable Portage Tree -- ideas
On Thu, Jan 05, 2006 at 11:42:36PM -0500, Andrew Muraco wrote: > Anyways, I would personally like to see if this can stir some interest. > I would be willing to help test and help make this GLEP a reality, > however I can not implement this myself as I lack python skills, but I > do want to help the portage team, as much as I can, to make this happen, > as I have some great benefit from this added feature. Whoever spear heads this is going to have to know at least a bit python, so I'd suggest you learn- pretty straightforward. Would suggest diveintopython.org for starters. Portage however, is not, but if you have questions you are welcome to ask in #-portage. Not saying we're going to do all of the legwork, but we are available as a resource. > Also, I hope I covered everything, and if the response from the mailing > list is good I may consider revising the existing GLEP and prepare it > for submittal to the council in feburary, or march, depending on how > much revision the GLEP needs, and if my idea is better or worse then the > current solution proposed. Probably better to iron out what y'all actually need and what the dev community is willing to put up with. Eg, would do some research into it, read the archives from last few wars over it, in general find (and address) the issues that lead to glep19 going still born. ~harring pgpt2KVMB9nK2.pgp Description: PGP signature
Re: [gentoo-dev] Re: GLEP 19: Gentoo Stable Portage Tree -- ideas
On Fri, Jan 06, 2006 at 09:27:23AM -0600, Lance Albertson wrote: > Chris Gianelloni wrote: > > On Fri, 2006-01-06 at 02:36 -0700, Duncan wrote: > > > >>OTOH, it's entirely possible a Gentoo /based/ enterprise distribution may > >>emerge at some point. IMO, however, there's enough conflict with what > >>makes Gentoo great at what it does today, that such efforts should be > >>separate from Gentoo itself. > > > > > > I don't disagree with you entirely, but there's nothing stopping us from > > *also* producing a "Gentoo Enterprise Linux" distribution. > > > > Like I said, I'll post my proposal, modified to fit the times, of > > course, as soon as I get a chance (it'll take a while to write back up). > > As seen from the discussion earlier this week, I don't think Gentoo has > the proper open-mindness to create a proper enterprise distro. Why should gentoo do it? While this statement likely will be twisted around as "gentoo developers don't want enterprise", what I'm asking specifically is why pulling and maintaining a subset of ebuilds is something that must exist within gentoo. We *do* have projects external to gentoo. Either way, 'open-mindness' bit is off- I'm mentioning this alternative due to the fact that it's not a matter of 'open-mindness', matter of interest. Can't make folk do what they don't give a damn about. > Just look at all the comments made from my thread earlier. > You cannot make an enterprise distro without > focus or direction and a leader. You'll be stuck in committee decisions > all the time. If y'all spawn an enterprise distro of gentoo you can run it however you want. Sub project or external, your stuff, your decisions- reaction was to y'all pushing that management structure upon gentoo as a whole, rather then the folk who desire it. Meanwhile, either we can discuss glep19 specifics, or continue working over an issue that bluntly doesn't matter right now- management structure matters not if y'all don't have the basic technical reqs nailed down. So can we stick tech crap at this point please? ~harring pgp8bRh00TqAl.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 19: Gentoo Stable Portage Tree -- ideas
On Fri, Jan 06, 2006 at 10:05:49AM -0500, Chris Gianelloni wrote: > On Fri, 2006-01-06 at 09:00 +, Chris Bainbridge wrote: > > On 06/01/06, Brian Harring <[EMAIL PROTECTED]> wrote: > > > > > Probably better to iron out what y'all actually need and what the dev > > > community is willing to put up with. > > > > > > Eg, would do some research into it, read the archives from last few > > > wars over it, in general find (and address) the issues that lead to > > > glep19 going still born. > > > > The problems being: > > > > 1) Manpower. There are already 10,000 open bugs in bugzilla (and > > growing) without adding more. > > This is probably the primary reason it died. This, of course, ties in > greatly to #2. Automation can reduce workload, within limits. Fex, scripting for yanking packages/deptree out of normal tree for merging into a g19 tree. Doing it by hand is possible, but error prone- same reason we have ekeyword, bit harder to screw things up via ekeyword (and it's a bit quicker in use then loading up $EDITOR). > > 2) Lack of interest. Most developers aren't interested in supporting > > "old" packages. I tend to believe interest is there- specifically resources/manpower to do it. That said, I don't think anyone has yet provided the folks who are interested any way to help- hell, can't even tap interested folk to help with maintaining the ebuild subset at this point since their is no subset. Hell, script work that needs be done, nothing has been done in that direction either- again, specifics haven't been stated, so there isn't anything to contribute on. Not going to find people doing all the work for you, but if _something_ were available for people to build from I'd expect more folks to jump in and help. > The only real "subset" that can easily work without dramatically > increasing workload is to limit to only arch rather than both arch > and ~arch. This is simply because it can be scripted. Agreed on pulling from arch. > > 3) The enterprise. Both of the above problems would be fixed if > > enterprises were contributing developers and/or money. However, they > > aren't, so why is that? The truth is most enterprises want to go to a > > big company to buy their software. They want one homogeneous binary > > system, not a flexible way of building packages from source, and they > > want someone else to do it and be responsible for it. > > While I don't think enterprise support is necessary to accomplish a > stable portage tree, it certainly wouldn't hurt. Tend to think either we wait for someone to step in and contribute (potentially waiting a _long_ time), or just do it. Kind of obvious my preferred route is "just do it" ;) > Truthfully, for any "large" enterprise, the company will be maintaining > a fair number of their own packages, with custom patches and whatnot. > Where I work, we use Red Hat Enterprise Linux. Why? Because we can pay > for support. That isn't the point I am going to make here, however. We > also have to maintain several hundred RPM packages that either are not > included in RHEL or modified by us in some way. What this means is we > are now in the business of maintaining a package set, using arguably > inferior tools versus ebuilds and portage. The binary support in > portage does make it very possible to "build once, deploy everywhere" > quite easily. The binary support is a bit weak- realistically, for a binpkg distro based off of gentoo, it would need a bit of an enema to improve it. So... consider that a statement of "proposals welcome on how to improve it". Right now, since (same with ebuild support) the format is effectively hardcoded into portage, it's hard to replace/make large changes to binpkg format. Abstraction work has/is underway to resolve that (something that help would be appreciated on also). ~harring pgpz8eZVbUoZQ.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
On Sun, Jan 08, 2006 at 01:15:22AM +0100, Carsten Lohrke wrote: > On Sunday 01 January 2006 06:30, Mike Frysinger wrote: > > Keep in mind that every resubmission to the council for review must > > first be sent to the gentoo-dev mailing list 7 days (minimum) before > > being submitted as an agenda item which itself occurs 7 days before the > > meeting. Simply put, the gentoo-dev mailing list must be notified at > > least 14 days before the meeting itself. > > I think I'm too late for this month, but want to put it on the table before I > forget about it. I'd appreciate a three months moratorium, disallowing > everyone to add new packages to the tree (despite new dependencies of > existing packages), so everyone is forced/asked to put his energy in existing > ebuilds, especially unmaintained ones. Sort of spring-cleaning, because parts > of the tree look like a dump. -1 Asking people to focus on cleaning the tree? Sure. Generate a list of candidates would help. Blocking new packages? No... ~harring pgpz6nfs2cWpa.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: GLEP 42 (news) Round Seven
On Sat, Jan 07, 2006 at 01:18:20PM +0100, Jan Kundrát wrote: > Duncan wrote: > > Because that code will be implemented in portage, and the portage dev > > likely to implement it said it was a superfluous reference. =8^) > > > > Still, I'd prefer it referenced just for definition's sake, but when the > > portage dev says it isn't a superfluous reference, and that particular > > section is specifying portage implementation... > > Nope, that particular section is specifying methods of interaction > between Portage and user. It's not an issue. So... no complaints, this means this *is* on the schedule for council, yes? ~harring pgptygbNibkIe.pgp Description: PGP signature
[gentoo-dev] DISTDIR ebuild changes.
Yo. Shouldn't be an issue unless you're doing something crazy, but the DISTDIR var exported to ebuilds will now point to an intermediate directory; all files stated via SRC_URI will be symlinks pointing back to the actual file in DISTDIR. Why? Well prior to this modification, it was possible for ebuild devs to overlook unstated SRC_URI files. Eg, direct access to DISTDIR, even if the file wasn't stated in SRC_URI, they still could use it. They also could commit it, where it would break for anyone who used it. Happens on occasion. Other angle is that RESTRICT="fetch", due to the fact portage isn't fetching, it was possible for the file to be left out of SRC_URI (thus no digest info). With this mod, if it's not stated in SRC_URI, it's not accessible. Basically, if your ebuild is broke, it *will* break now rather then working locally for you. Downside is that since certain class of ebuilds don't state their files in SRC_URI (namely subversion and cvs based ebuilds), they're broken by the change. So... PORTAGE_ACTUAL_DISTDIR is added (eclasses modified already for it), that holds the actual DISTDIR location. Don't use PORTAGE_ACTUAL_DISTDIR unless you have to. Four cases where it's valid in the tree, shouldn't be anymore. That var *will* go away when/if cvs/svn support is via SRC_URI. Meanwhile, notifying y'all so any further complaining/issues are stated before this goes stable. Bug in question is 117440 http://bugs.gentoo.org/117440 Questions, either comment here or track me down in irc. ~harring pgpQMSRBLRYeM.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
On Sun, Jan 08, 2006 at 02:40:47PM +0100, Carsten Lohrke wrote: > On Sunday 08 January 2006 01:35, Stuart Herbert wrote: > > I agree that some cleaning is needed (and some of my packages are > > desperate for it!), but I'm totally opposed to this idea. I think the > > idea of shutting up shop for three months (presumably with a "closed > > for refurbishment" sign on the door) would let down our users who rely > > on us for regular package updates, and would be a massive PR disaster. > > Cleaning is something that has to happen all the time; it needs to be > > a natural and sustainable part of what we do every day. > > As Donnie already pointed out, I did not mean version bumps, but only new > packages. > How about this idea: Everyone who adds a new package, has to check > and fix an unmaintained package before. Guessing you missed the previous flame war about how trying to force people to do something doesn't actually work? > This should be a non-issue for > seasoned developers, You're assuming seasoned devs don't occasionally go MIA on QA/maintenance? It's not the case... > but would slowdown those who continually add new > packages [ snip vitriolic opinions ] If you've got an issue with devs adding stuff and abandoning/not supporting their stuff, hey that's fine, bitch at QA. Don't go freezing the whole tree just because you're after slapping at a couple of devs over perceived wrongs. > Don't you think that it is pretty much barefaced to let a small group do the > dirty, boring and annoying work, while those who don't care a bit can > continue to do so?! If you've got an issue with certain devs (seems to be the case from your statement), take it up with QA/ombudsman, not the loop around attempt you're doing here. If you're after trying to decrease the unmaintained packages, like I said, generate a list _from the tree_, compare it to bugs, etc. Do the legwork, kick off the effort to cover the gap. Basically, you want to decrease bugs for unmaintained, decrease the gap of maintained vs unmaintained, work on _that_ rather then trying to force everyone to drop what they're doing and fix an issue they're already working on at their own pace. Folks *are* handling retirement of unmaintained packages, and taking on maintainance of packages already- just watch -dev for the occasional announcements if you think otherwise. ~harring pgpDAMqm725Du.pgp Description: PGP signature
Re: [gentoo-dev] Re: GLEP 19: Gentoo Stable Portage Tree -- ideas
On Sun, Jan 08, 2006 at 10:55:50AM -0600, Lance Albertson wrote: > A few rough ideas that just popped in my > head is either packing all of these versions into one tarball (not even > sure if thats feasible) Ugly, binpkgs are bzip2ed tarballs + xpak at the end of the bzip2 stream, jamming multiple contents sets in would lose the ability to just untar the bugger to the fs in worst case. Plus... it's nasty from a format standard, trying to determine which contents set to pull. Basically have to jump to eof, read the footer, either store _all_ offsets there (extension of xpak format), or jump from there to the previous xpak, repeat till you've found what you want. > , or creating a hashed suffix based upon the > useflags enabled/disabled at the time that you append to the tarball name. +1 on mangling the name. Need something for keywords anyways. Alternative is expanding the bintree format, cat/pkg-ver being a directory, with the binpkgs held with in... Either way, bintree/binpkg format are all rolled into one mess, as stated, open to proposals to make it less sucky. ~harring pgpImi4Qu9x9S.pgp Description: PGP signature
Re: [gentoo-dev] Projects and simple guides
On Sun, Jan 08, 2006 at 06:07:48PM +, Renat Lumpau wrote: > On Sun, Jan 08, 2006 at 06:59:40PM +0100, Diego 'Flameeyes' Petten? wrote: > > GDP might be the place where to put them, but as they are mainly > > developer-oriented, they might be better accessed directly by devs (at > > least > > for the first steps until they are drafts). > > > > What people think about this? > > Devwiki Devwiki is effectively inaccesable to non gentoo folks (whether in access, or in navigating the beast), thus it's a no go. Any docs generated should be googable imo. ~harring pgpk95w9iqaLY.pgp Description: PGP signature
Re: [gentoo-dev] Projects and simple guides
On Sun, Jan 08, 2006 at 11:30:16PM +, Stuart Herbert wrote: > On Sun, 2006-01-08 at 12:54 -0600, Lance Albertson wrote: > > > We could start a public wiki displaying all herds and projects. It would > > > be great to add some low level docs, herds/project goals, ideas and so. > > > Even the users could be allowed to edit and share information. > > > > Anything like that will need to be approved by the GDP and a GLEP. > > Are you sure? The new metastructure makes it perfectly clear that > "competing" projects are okay. The GDP does not have a monopoly on > documentation, only on what gets published through the /doc URLs on > www.g.o. Would like to see GDP reiterate this view actually, since I've a distinct memory last time I asked in irc about it I got an opposite answer from them. Regardless, (imo) it's already been laid out why guideXML'ifying everything doesn't totally work. Three reasons... A) bit of work required just to jot down a quick list of "this is broke, fix it" that's going to be thrown out 2 weeks down the line. B) guideXML requires actual vcs/shell access to commit the changes. Portage group relies fairly heavily on non-dev help to keep things going (throw cookies at antarus and zmedico, since they're the ones I speak of). Yes (generally speaking) non-devs will be minted at some point as devs if they've put in the effort, but there _is_ a sizable delay built in, thus no vcs/shell till after we've deemed they're going to be around for the long haul. C) delay in material commits to vcs actually hitting the web. Kind of hard discussing in irc what needs to be done and having the list that's being built up delayed due to cvs up reasons- yes this seems minor, but it results in people writing up crap text/html pages temporarily for the need, then dumping it into docs. Extra effort, I'd rather just modify the list in situ. Basically... docs route maintains the artificial barrier between devs and non devs, which bluntly, is stupid. If someone is contributing work, they're contributing work, as long as it doesn't suck I'm going to use their work regardless of whatever we've deemed them gentoo wise. Yes, for portage docs we have to lock sizable chunks of it down, but that is locking it down to the groupping of portage devs- both gentoo dev and non-gentoo dev. Note also I'm speaking mainly from a developmental angle- I'm not necessarily advocating that _non_ developmental docs be wikified, although there are pros to doing that. ~harring pgpK9wa6fwjNf.pgp Description: PGP signature
Re: [gentoo-dev] Re: ca-certificates PDEPEND
On Mon, Jan 09, 2006 at 05:28:04PM +0100, Andrea Barisani wrote: > On Mon, Jan 09, 2006 at 05:21:42PM +0100, Jakub Moc wrote: > > > > 9.1.2006, 17:12:31, Andrea Barisani wrote: > > > > > On Mon, Jan 09, 2006 at 11:08:38AM -0500, solar wrote: > > > > >> > > >> Do you think the PDEPEND of the ca-certs should be tied to a USE= flag? > > >> If so should it be a 'no*certs' flag or a USE=cacerts ? > > > > > USE=cacerts sounds the proper course of action to me. > > > > NOT until use-based deps are in place, plzktnxbye!!! Don't break the damned > > realplayer thing again. > > It's the realplayer thing that should be fixed. Can't believe that > ca-certificates got relatively quiet as a PDEPEND because of that ;). I bitched for exactly that; we can't mirror their files, and having the package non fetch restricted is questionable from a license standpoint anyways. Either way, one thing that *should* be noted here is that this still doesn't totally fix the issue for realplayer. Curl won't honor/use the cacerts package for example, so we still have the same bug, just different fetcher. Adding cacerts to the pdepend effectively is expansion of allowed SRC_URI targets- right now we require all uri to be on standards ports (443, 80) for restricted networks. Now, via this change, we require FETCHCOMMAND to be a binary that supports cacerts. We also require any https proxy to support/allow cacerts also, if my understanding of https proxying is correct. Finally, this also requires infra to now run with cacerts on for the master mirroring box. Basically... I'm still against this change. We require fetchers that support http, and support the standard chain of trust for https. I don't like changing the restrictions just for a (bluntly) stupid upstream that forces downloads through https. ~harring pgpgvMkDOSk3W.pgp Description: PGP signature
Re: [gentoo-dev] Projects and simple guides
Sending this to the ml, tom already has heard the reasons but throwing them out for others to comment on... On Mon, Jan 09, 2006 at 04:47:57PM +, Tom Martin wrote: > > I realize this doesn't address the *rest* of what you said, though... > These little 'howtos' are potentially very short, and guideXML would be > overkill. RST is absolutely perfect for this kind of thing: quick and > easy to write, powerful, and legible in raw form. It's also easily > converted to any number of other formats. Agreed. > A new CVS repository containing these little howtos that is accessible > with viewcvs would be perfect, if you ask me. There would be proper > version control on the files and they would be read/write for > developers and read-only for users (otherwise the potential of > vandalism etc. is too high). This is, in my opinion, how things should > be for these simple developer guides. disagree. :) Note my comments about allowing non gentoo personnel to modify the docs. I'm not minting half devs just so they can do some doc work, nor is it efficient for trusted devs to be passing patches through me just because they haven't yet been around long enough where we mint 'em. > The whole wiki-for-everything idea really annoys me. It forces > a web browser on me, and this is particularly naff when it comes to > editing. It's also really bland and boring, and completely unoriginal. Note that what's being pushed here is the desire for a faster model of doc developing; GDP/guidexml docs are good for long term stable docs. They suck royally however, if we're talking about developmental docs for portage where things move quickly. Less work required to maintain the documentation, higher chance the docs will actually be up to date/maintained. Note that's my opinion, I don't dislike guidexml, I just prefer to not dink around with it for docs that are going to be rapidly changing. > I still haven't fixed the other two points Brian mentioned, but I don't > really think they're all that serious. If a user sees an omission, he > can drop a mail to the guy who wrote the guide. There's really no > reason to file bugs for anything like this. We're not talking about a guide here- two scenarios. flameeyes rapid development of docs, improving the quality- area to hash out the doc before slapping it up in official docs (and no, labelling it unofficial doesn't fly when we're talking about initial hammering out of the doc). Essentially, a chalkboard/whiteboard for projects- communal scratchpad of what the current issues are (and I mean *current*, that day), proposals for apis, use scenarios, rough design documents. We could (and do) do this via devspace, but that suffers the exact issue I'm after addressing- not everyone involved can modify it (for devspace, only one person can modify it). > Allowing universal r/w is > asking for vandalism. As for the third point -- concurrency -- this is > exactly what any VCS is supposed to fix. We live with it with the > tree's CVS, I'm sure we can live with it for this. Where exactly did I ask for universal r/w? I've seen a lot of args against this based upon "joe idiot will screw up the page". What I'm after is non gentoo personnel capable of handling the docs- does that mean everyone? No. It means people not minting people just so we can have them do a bit of doc work, essentially, nuking the overhead. Again, vcs is worthless if you don't have access to it. Non gentoo folks do not have access to the vcs, thus we're right back to my point for why a wiki is useful- we don't have to mint a couple dozen part time contributors as devs just so they can do their work. Proposals/alternatives thus far are basically reinventing wiki's, just slower. That's kind of a sign that people dislike wiki software they've seen- I've yet to see anyone level arguement against the model of doc development I'm after however. So... if the core need isn't an issue, wth should we reinvent the wheel and create our own wiki analog? ~harring pgpAknTOSAknI.pgp Description: PGP signature
Re: [gentoo-dev] A New Linux Way
Crap. Guess it's time to rename the portage rewrite branch (bugger, we were here first :P), especially since they're stating they'll have a saviour package manager... Think it's time to use my preferred name, bcportage- bastard child of portage ;) ~harring pgp81jtcXq0Tt.pgp Description: PGP signature
Re: [gentoo-dev] Re: Gentoo "Stable" Portage/Releases
On Wed, Jan 11, 2006 at 10:38:30AM -0500, Chris Gianelloni wrote: > On Wed, 2006-01-11 at 00:03 -0700, Duncan wrote: > > Remember, portage already has a decent amount of signed content > > verification builtin, and is getting more. Just because it's not > > currently used, as the debate on strength and keyring handling hasn't been > > settled, doesn't mean the capacity doesn't exist. > > One other advantage with this is we will be starting from a known > portage version. This allows us to not have to worry about backwards > compatibility. Reliant on portage- we're sitting on forward/backward compatibility handling for ebuilds (EAPI), few months before we cut over and require people to be running an EAPI capable portage- that said, we don't have any versionning yet for profiles. Proposals welcome for that one, since it's required (recall the 2.0.50 bug for cascaded profiles, anyone? ;). ~harring pgp29kK5uHwCl.pgp Description: PGP signature
Re: [gentoo-dev] /sbin /usr/sbin security hole
On Tue, Jan 17, 2006 at 02:17:50PM +0100, Paweł Madej wrote: > Hello, > > Today i've noticed that common user do not have /sbin and /usr/sbin dirs > in their PATH but they can start all the tasks from that directories for > example on server machine someone could make /sbin/shutdown and turn the > server off. For me it is very big security hole. Just because a binary is accessible, doesn't mean the user executing it has the keys to the kingdom- the binary is executing under that user, meaning the execution context can do only what the user can do. This is why setuid can be problematic, it makes the binary execute under the owner rather then user calling it- non root can execute with root privs. Note also I said problematic- there are cases where this is useful/needed (mount for example), just has to be managed carefully. Either way... this isn't a security hole, would suggest you try executing some of the bins- as stated in the other email, this isn't an issue unless the user has gone and flagged those binaries setuid (eg, user did something _really_ dumb). Thread should move over to gentoo-user for further details on setuid (after a bit of googling hopefully :) ~harring pgpxRFSonbMHM.pgp Description: PGP signature
[gentoo-dev] NFP lack of progress
Hola. Email's pretty simple- from where I'm sitting, there doesn't seem to be any actual progress on trustees issues. Current issues with no progress- 1) Copyright assignment. Check the nfp archives, last comment is sep 26th, seems to be totally dead. http://news.gmane.org/gmane.linux.gentoo.nfp/ 2) bylaws. They're proposed. About it. Last update to the bylaws doc was 10/24/05, http://www.gentoo.org/foundation/en/bylaws.xml 3) quarterly filings. We've got 2nd quarter '05 up (04/01/05-07/30/05). Where's 3rd? 4th actually being worked upon? I'm assuming the pages haven't been posted but the paperwork (whatever there may be) has been handled. Additionally, bank transfer is underway, but donnie is responsive on it so not raising it as an issue. General commentary from nfp members who have responded when I've poked for updates is that there isn't much to do- 'k, we still have outstanding issues that don't seem to have any progress occuring. I've tried getting info out of -nfp ml regarding actual progress, but thus far either no responses on issues at hand, or a repeat of same state. So I'd like to know the following- 1) where we're _actually_ at on these issues. 2) who is working on what 3) what _exact_ issues are holding folks up. 4) what is being done to resolve the hold ups. 5) What actual progress/work has been done thus far (no, don't need to document something publically viewable like "wrote bylaws") 6) A rough schedule of when things are going to be accomplished. Not asking for hard figures, but if you're held up by X, I'd like to know when you expect X to be done so we can gauge how things are going. Yes... email is a bit forceful, but if you look through the nfp archives, this seems to be the remaining option available. Additionally, we *do* elect trustee members, so transparency here is a bit of requirement- otherwise, it's pretty damn hard to vote out the slackers if we can't identify who they are (this is assuming folks are slacking of course, which may not be the case). Finally, this is intentionally sent to -dev rather then the sekret flame-war arena that is -core, as I stated above, transparency is required. ~harring pgpB8LFJxqBEF.pgp Description: PGP signature
Re: [gentoo-dev] Compilation in src_test
On Fri, Jan 20, 2006 at 08:05:42PM +, Ciaran McCreesh wrote: > Say we have an autotooled package that provides a library. Say also > that this package provides several well written test programs that are > listed in Makefile.am under check_PROGRAMS. When emake is run, the > library will be built, but the test programs will not be. When make > check is run, the test programs will be built then run. Two problems... > > Firstly, this will result in non-trivial things being compiled in > src_test. Is this an issue? Imo, this is valid- it's test related, only kick off the work if it's needed within that phase. ~harring pgp57OCjcbCjj.pgp Description: PGP signature
Re: "Environement categories" (was Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2)
On Mon, Jan 23, 2006 at 07:28:05PM +0100, Danny van Dyk wrote:
> Donnie Berkholz schrieb:
> | Marius Mauch wrote:
> |>I meant the option is redundant if it just triggers a feature setting,
> |>as it's the same as `FEATURES=debug-build emerge foo`
> |
> | OK, where's my package.features and packages.cflags files then? I can do
> | what I want through Mike's proposal, which is to build a specific
> | collection of packages with debugging. I also don't need to duplicate
> | the same list of packages in one file with FEATURES=nostrip and in
> | another with debugging CFLAGS.
>
> I'd love to have one package.env (or similarly named) file that can set
> environmental options on a per-package-base. This is just a proposal,
> but i personally would like it this way:
>
> # First define a category of environmental options:
> stable=( \
> "ACCEPT_KEYWORDS=\"arch\"" \
> "CFLAGS=\"-pipe -O -march=foo\"" \
> )
We've already got package.keywords...
Not saying it's the best, but muddying up the existing configuration
with N ways of saying the same thing imo isn't the sanest.
> debug=( \
> "FEATURES=\"debug-build keepwork\"" \
And there is the kicker. Portage has globals, which are in various
states of use- most of the features you're looking to tweak *are*
effectively globals already.
So... you need seperate configuration instances. This gets ugly since
not all code uses a passed in config instance, some falls back to
global access (just the same as not all code uses passed in dbapi's,
they use the global portage.db).
The config representation does a nasty little dance where it pushes
changes on, then pops them (moreso it just flat out regenerates the
settings)- extending usage of that really isn't a good thing imo,
since it's fundamentally the wrong design. Hell, such an approach
won't fly anyways for any real possibility of threaded execution
(parallel-fetch doesn't count, it's a fork for exactly this reason).
See where I'm going with this, and why the portage crew occasionally
make reference to design flaws? :)
Might I suggest this one just get shelved for a while? I'm not much
for spanky's proposal from an implementation side of things, but it
skirts the areas I'm concerned about (thus I'm mostly neutral on it),
but varying all configuration data per node is a whole different beast
from spanky's proposal- it's not skirting the areas that are icky.
Realistically, need to design the bugger so configuration data is
pushed down to each level/abstraction rather then a global obj; do
that, and it's easy to vary settings per node; rewrite is designed
this way, just not finished.
Personally, I'd rather revisit this a few months down the line- right
now it's too nasty of a hack to even consider it in stable.
> This proposed format could even be more easily parsed when split into to
> files. One file to define the categories and one to define the
> package-to-category bindings. The first file would be pure bash and
> could be loaded like this:
>
> mycat=$(
> . ${CATEGORY_FILE}
> cat=${!cat}
> for i in $(seq 0 $(( [EMAIL PROTECTED] - 1)) ) ; do
> echo -e "${cat[${i}]}"
> done
> )
Bash side overrides are a no go; either the resolver would have to
spawn a shell instance for processing each node, or portage would have
to know how to parse and execute shell (hard... very hard).
So... at least the bash side of it, not really doable imo. Same
reason you can't use bashrc to affect features (for the most part),
by the time that code is executed it's too late in the game.
~harring
pgpZMabwXoRwB.pgp
Description: PGP signature
Re: "Environement categories" (was Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2)
On Tue, Jan 24, 2006 at 08:06:12PM -0500, Mike Frysinger wrote: > On Tuesday 24 January 2006 01:44, Brian Harring wrote: > > Might I suggest this one just get shelved for a while? > > everything that gets shelved portage way stays that way for *quite* a while If people don't give a damn about it, yes, that's true. Not the case here. > i would be ok with implementing the back end (i.e. FEATURES=debug-build) but > putting off the front end (i.e. emerge --debug-build) Front-end doesn't matter, it's the back-end that's the concern. Clean up the backend in stable, and it's fine- hence the "shelve it"; fix the backend instead of tagging it half way in. ~harring pgpnXO9Ud50CA.pgp Description: PGP signature
Re: [gentoo-dev] Unmasking modular X
On Wed, Jan 25, 2006 at 08:27:22PM +0900, Jason Stubbs wrote: > On Wednesday 25 January 2006 18:10, Donnie Berkholz wrote: > > Jason Stubbs wrote: > > > DEPEND="x11-base/xorg-x11" # wrong > > > DEPEND="virtual/x11"# wrong > > > DEPEND="|| ( x11? ( virtual/x11 ) )"# wrong > > > DEPEND="|| ( misc/atoms virtual/x11 )" # right > > > > > > There's a small possibility that broken packages will be missed by this, > > > but is there any chance that valid packages will be incorrectly flagged? > > > If this gets a go-ahead, it'll be easy enough to get in for the next > > > release (which is likely this coming Saturday). > > > > It sounds right. There should be no valid instance of virtual/x11 that > > is not within an || dep. > > I've implemented and tested the check locally but haven't committed it yet. > Repoman isn't really structured to allow for tests against a set of ebuilds > so the checks are done on every version. There is also definitely one false > positive (virtual/x11-6.8) so, for this and the fact that every version is > tested, it would probably better to just make it a warning. Thoughts? Curious about the mechanism you're using for this... a hardcoded set of atoms in repoman doesn't sound very nice to me ;) ~harring pgpDCAosSDcJy.pgp Description: PGP signature
Re: [gentoo-dev] Unmasking modular X
On Wed, Jan 25, 2006 at 09:18:28PM +0900, Jason Stubbs wrote: > On Wednesday 25 January 2006 20:46, Brian Harring wrote: > > On Wed, Jan 25, 2006 at 08:27:22PM +0900, Jason Stubbs wrote: > > > On Wednesday 25 January 2006 18:10, Donnie Berkholz wrote: > > > > Jason Stubbs wrote: > > > > > DEPEND="x11-base/xorg-x11" # wrong > > > > > DEPEND="virtual/x11"# wrong > > > > > DEPEND="|| ( x11? ( virtual/x11 ) )"# wrong > > > > > DEPEND="|| ( misc/atoms virtual/x11 )" # right > > > > > > > > > > There's a small possibility that broken packages will be missed by > > > > > this, but is there any chance that valid packages will be incorrectly > > > > > flagged? If this gets a go-ahead, it'll be easy enough to get in for > > > > > the next release (which is likely this coming Saturday). > > > > > > > > It sounds right. There should be no valid instance of virtual/x11 that > > > > is not within an || dep. > > > > > > I've implemented and tested the check locally but haven't committed it > > > yet. Repoman isn't really structured to allow for tests against a set of > > > ebuilds so the checks are done on every version. There is also definitely > > > one false positive (virtual/x11-6.8) so, for this and the fact that every > > > version is tested, it would probably better to just make it a warning. > > > Thoughts? > > > > Curious about the mechanism you're using for this... a hardcoded set > > of atoms in repoman doesn't sound very nice to me ;) > > There's no other way to do it given repoman's state and the > requirements. I was talking long term. One time kludges suck (but occur), would like to see something a bit less short sighted for this though- variants of this request will come up sooner or later (most likely in the form of can we warn/error on new commits of deprecated deps). Might be wise discussing potential solutions for it. > If you'd like to make repoman pluggable, convert all the > current checks to plugins and then make a new plugin for this one and do it > all by this weekend, be my guest. :P Harass antarus, he's been working on integrating swegeners rewrite of repoman checks (plugins effectively) into mainline repoman. :P Besides, a massive change to repoman with 3 days to go is a no go anyways (kind of limited the choices there) ;) > Besides, what's wrong with hardcoded atoms in repoman anyway? portage (by extension repoman) is used beyond gentoo. Not everyone may be at the same step as we are for mod x. End result of hardcoding gentoo specific crap into repoman is that you force derivatives of gentoo (vidalinux or genux fex) to start hacking up portage source to remove said hardcoding. Portage exists beyond gentoo; thus gentoo specific hacks should be avoided when possible. So... long term? ~harring pgpgOctY1JxVW.pgp Description: PGP signature
Re: [gentoo-dev] Unmasking modular X
On Wed, Jan 25, 2006 at 06:06:02PM +0900, Jason Stubbs wrote: > On Wednesday 25 January 2006 17:43, Donnie Berkholz wrote: > > Jason Stubbs wrote: > > > I'm not exactly sure what you mean by "broken" in the first paragraph nor > > > how a check can help with unmaintained (=no commits, no?) packages, but > > > if > > > a repoman check will hasten package porting while smoothing the users' > > > ride, I'm personally all for it. > > > > By "broken" I mean unported. In other words, directly depending on > > either virtual/x11 or x11-base/xorg-x11. The check will help discover > > unmaintained packages by not allowing people to do flyby fixes without > > also fixing this. > > > > What can I do to speed up the process of getting this into a 2.1 > > release? Keep in mind my python is beyond bad. > > Perhaps not so easy. What specific states need to be checked for to regard a > package as broken? Depending on "x11-base/xorg-x11" is one. Depending on > "virtual/x11" seems to be valid looking at the porting guide though. Would > considering a package broken if it contains "virtual/x11" where the token > immediately preceding the surrounding brackets is not "||" be correct? > > DEPEND="x11-base/xorg-x11" # wrong > DEPEND="virtual/x11"# wrong > DEPEND="|| ( x11? ( virtual/x11 ) )"# wrong > DEPEND="|| ( misc/atoms virtual/x11 )" # right > > There's a small possibility that broken packages will be missed by this, but > is there any chance that valid packages will be incorrectly flagged? If this > gets a go-ahead, it'll be easy enough to get in for the next release (which > is likely this coming Saturday). Patch misses on || ( virtual/x11 ) || ( x86? ( virtual/x11 ) b ) via the latter, kind of guranteed it's going to miss on || ( x86? ( valid-dep ) virtual/x11 ) also... Fixing it's a bit fun. fixed a few of the issues in dev.gentoo.org/~ferringb/deprecated-x11-scan.py , but some of the cases still exist. ~harring pgpQXvvdRTsFM.pgp Description: PGP signature
[gentoo-dev] New Dev: antarus (Alec Warner)
Hola all- We've got a new portage dev; Alec Warner, aka antarus- aside from doc work, he'll be doing repoman work and the usual random bug squashing. His words- I work at The Division of Engineering Computing Services at Michigan State University. I serve primarily as an undergraduate web development slave. I also contribute to administrating the unix environment although I haven't quite succeeded in converting all our machines to Gentoo ;) I am currently a senior, going after a Computer Science Bachelors with a cognate ( minor basically ) in Japanese. GO gentoo-jp :) My hobbies are (besides gentoo) slacking off on irc, playing RPG's on my PS2, playing DDR on weekends with friends, going out to eat (breaks my wallet :/) mini-golf, biking, reading books, watching family guy...I think that about covers it. Please say hello to him, and start the usual process of trying to get him to implement your pet features ;) ~harring pgpK2oeOV2vyL.pgp Description: PGP signature
[gentoo-dev] New Dev: zmedico (Zac Medico)
Hola all- Well looky here, we've got another new portage dev to report- Zac Medico (zmedico). Areas of focus thus far are general stable work, and work on the rewrite (you can thank him and marienz for the test framework work). Additionally, Zac is the maintainer of two external projects- http://freshmeat.net/projects/linkbrowser/ http://freshmeat.net/projects/rimanip/ Finally, he lives in Orange County, California, and is interested in progressive politics related to social justice and environmental concerns. So... say hello everyone, but kindly no leg humping (this means you Battousai). :) ~harring pgpOuNHOdXhPP.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Tue, May 16, 2006 at 04:15:49PM +0100, Stephen Bennett wrote: > If noone has any strong reasonable objections, I'd like to add a > Paludis profile to the tree. This would use Paludis as the default > provider for virtual/portage (which is a less than ideal name, but that > is another discussion entirely), and provide ebuild devs with a place > where they can try out some of our profile enhancements should they > want to. It is worth noting on the last point that most of these are > Comments? Maybe I'm daft, but why does this need to be demoed in the live tree? Use an overlay (y'all have one already anyways). Reasons why this is a bit daft- 1) changes to the eapi=0 ebuild standard; renaming of vars (PORTAGE_* -> PALUDIS_* namely), dropping of all local vars during phase changes (since y'all lack ebuild, it'll rear it's head mainly during unmerge), effective dropping of config phase (another place it would rear it's head)... Mind you that's from a quick read through of your ebuild env reimplementation, stated the issues already and they still remain- incomplete support for the standard is one thing, changing it is another (y'all are doing the latter). 2) N profile inheritance- the parents change (N entries instead of one) needs to be protected so that specific profile is only usable by a package manager (whether portage, pkgcore or paludis) that actually does N parent inheritance. This is why N profile inheritance has never been added to portage (it's honestly a one line change in portage)- the change must not be introduced without protection, else the user's system set can become drastically reduced. It's not an easily addressable problem (all solutions sans a new profile directory leave open the potential for users to get bit), ignoring it is a no go. Yes, you're after demoing capabilities- problem is that it's exposing potential horkage in a production tree, wrong place to be demoing. 3) vdb CONTENTS change of dev/fif to misc. It's dumb, but that change renders vdb entries incompatible- iow, proper usage/conversion to paludis requires a new installation (or translation script, both to/from portage). So... short version, introduction of the profile allows for curious users to get bit in the ass by intentional dropping of compatibility (profile level changes are one thing, changing the ebuild standard is another). In light of that, why should it be demoed in the tree where the only use of it is to bootstrap a new installation? Just overlay it, y'all should be maintaining an overlay fixing ebuild incompatibilities anyways. > That's my proposal. The benefits I like to think are obvious. The > drawbacks are, as far as I can see, in tree size, which should be > minimal. Benefits of demo'ing for a minority (300 devs) must be balanced against risk (adding profiles that portage can eat itself on, the default virtual change doesn't address it, eapi incompatibility, vdb changes )- wrong place to be deploying incompatibilites that paludis introduces is into the production tree without appropriate containment/protection. The gain of the profile is that you can do a few new tricks for folks doing boostrapping experiments- why not just introduce an ebuild that sets up the new profile in a temp overlay? Still have the sandbox for experimenting/demoing, but it minimizes the potential borkage folks can hit by doing stupid things. ~harring pgpC2lhMLRD4q.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Tue, May 16, 2006 at 05:47:42PM +0100, Ciaran McCreesh wrote: > On Tue, 16 May 2006 09:16:18 -0700 Brian Harring <[EMAIL PROTECTED]> > wrote: > | 1) changes to the eapi=0 ebuild standard; renaming of vars > | (PORTAGE_* -> PALUDIS_* namely) > > What eapi=0 standard? We emulate Portage internals where it's found to > be necessary, and don't otherwise. eapi=0 is what 2.1/2.05x supports. Features are fine, but for gentoo backwards compatibility *is* a concern, as such dropping the bits that you dislike (but existing ebuilds rely on) is a no go. > | dropping of all local vars during phase changes > > Again, we emulate Portage misfeatures only where it's found to be > necessary. See above... > | Mind you that's from a quick read through > | of your ebuild env reimplementation, stated the issues already and > | they still remain- incomplete support for the standard is one thing, > | changing it is another (y'all are doing the latter). > > What standard? Are you trying to say that Paludis should emulate > Portage's bugs, because the standard is "exactly what Portage does"? See above. Paludis (my view) is a rewrite of portage, rather then a reimplementation- as you've stated, dropping the stuff that you deem misfeatures. This is fine, but portage *is* what gentoo is based uses now, and what all ebuilds have been written to, as such you need to either support the misfeatures or have a bullet proof transition plan to deal with the things you decided to carve out. This is directly relevant because you now want to modify the gentoo-x86 repo to standards gentoo does not actually support. Call it "dropping the misfeatures", but it's the reality of backwards compatibility (something that has been kicking portage devs in the nuts for years now). > | 2) N profile inheritance- the parents change (N entries instead of > | one) needs to be protected so that specific profile is only usable by > | a package manager (whether portage, pkgcore or paludis) that actually > | does N parent inheritance. This is why N profile inheritance has > | never been added to portage (it's honestly a one line change in > | portage)- the change must not be introduced without protection, > | else the user's system set can become drastically reduced. It's not > | an easily addressable problem (all solutions sans a new profile > | directory leave open the potential for users to get bit), ignoring it > | is a no go. > > Uh, no. Any user who isn't using a package manager capable of multiple > inherits shouldn't use a multiple inherits profile. There's plenty of > precedent of intro Feature introduction is done via introducing support, then sitting on it for ~6 months to ensure folks don't get bit by it- notable exception was virtuals/* metapkg, although the buttload of bugs from it is a demonstration of *why* this route must be taken. This is also why eapi came about- faster introduction of compatibility breaking changes. Meanwhile, the precedent for changes to the tree (pkg manager related changes) is that of "don't break shit for users", introducing N parent inherit profiles into the tree still qualifies as a concern- as stated, you're after demoing capabilities, do it somewhere other then production data. > | 3) vdb CONTENTS change of dev/fif to misc. It's dumb, but that > | change renders vdb entries incompatible- iow, proper usage/conversion > | to paludis requires a new installation (or translation script, both > | to/from portage). > > Had you bothered to read the documentation, you'd know that we don't > claim nor desire VDB compatibility with Portage, and don't encourage > installs onto the same ROOT. Snarky response aside, I read the src (note the env screwups I've pointed out, and the fact y'all don't support try eclass unified overlays), and your documentation- the point was that paludis can only be used for new installs, and you're locked to paludis as your pkg manager at that point without a translation script. Trying to make it clear that paludis isn't something you try out for a bit, then revert back to portage- it's a full rebuild. That seriously limits the usefulness of the requested profile. > Because Paludis is now a viable alternative to Portage and can be used > to install and maintain a real system. We already support enough of the > "ebuild standard" and emulate enough of Portage's bugs to install Just because something is a viable alternative to portage doesn't mean the tree should be mutated to the alternative, especially when the alternative breaks standards that are in the tree already. Call it "misfeatures of portage",
Re: [gentoo-dev] Paludis and Profiles
On Tue, Jun 13, 2006 at 06:28:41PM +0100, Stephen Bennett wrote: > Brian Harring wrote: > >The gain of the profile is that you can do a few new tricks for folks > >doing boostrapping experiments- why not just introduce an ebuild that > >sets up the new profile in a temp overlay? > > No, the gain is that one could sanely run a Paludis-based system without > needing an external overlay, and without having to update said overlay > whenever the base profiles in the tree change. Bluntly, why should the tree be modified for a minority? Being generous, lets pretend y'all have 300 users- why should incompatible changes be added to the tree (say 300k users) that can bite 299,700 users in the ass for the benefit of 300 users? N parent inherited profiles *is* a change that can bite users in the ass, and it's not an obvious incompatibility unless you know it exists. Ebuild level incompatibility is there also, and the only way that's going to be resolved is by inspection of each ebuild. Note I said inspection- just the same as loosing the USE flag state for when re-executing the env for an unmerge, loosing local non exported vars has the same potential for change. Not opposed to y'all ironing it out in an overlay and proposing the switch (with a sane transition plan)- am opposed to the "lets just do it and ignore the consequences to the userbase" mentality that such requests imply. ~harring pgpErGzCfUrje.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Tue, May 16, 2006 at 07:07:05PM +0100, Ciaran McCreesh wrote: > On Tue, 16 May 2006 10:33:56 -0700 Brian Harring <[EMAIL PROTECTED]> > wrote: > | > What eapi=0 standard? We emulate Portage internals where it's found > | > to be necessary, and don't otherwise. > | > | eapi=0 is what 2.1/2.05x supports. > > That's not really true. Relying upon "anything that Portage handles", > including relying upon Portage bugs and internals, leads to broken > ebuilds when said things change. ...which is why the ebuild env for portage is extremely carefully maintained- mistakes may occur, but willy nilly changes don't. Regardless, at least for gentoo it still however *is* the standard for ebuilds, breaking the 'standard' out of portage is fine, changing intrinsic parts of the standard isn't. > | Features are fine, but for gentoo backwards compatibility *is* a > | concern, as such dropping the bits that you dislike (but existing > | ebuilds rely on) is a no go. > > You're acting like Paludis is dropping something huge here. Not > emulating a few weird PORTAGE_ variables that nothing uses is not > breaking eapi. If ebuilds genuinely rely upon something, we emulate as > necessary. Then I'll state it again; you're changing the core environment handling via intentionally dropping all local vars defined per phase run. Add binpkgs, and try it- you'll get some fun behaviour there. > A 'rewrite' implies that we're starting from "what Portage does", and > making something that does the same thing in the same way. That's not > how it's being done. We're looking at it a) from what ebuilds do, and > b) from what the program is expected to do, and then filling in the > middle. The only part that's really at all close to Portage is the bash > stuff for ebuilds, and that's pretty much necessary because of the > ebuild <-> package manager interface thing. > > *shrug* Your perception on this one's probably skewed if (as it seems) > you've been focusing on the trivial and easily replaceable bash part, > rather than the interesting things which are done in C++. The bash part is all that matters, hence why I'm focusing on it- as you stated above, the data (ebuilds) handling is what matters. Stating that the bash concerns are trivial while the C++ side can be interesting is ignoring the point, the bash bits must match- I don't care if it's C++ or python or haskell for the high level, the ebuild env support must *not* induce any intentional changes that break ebuilds. > Again, not really true. Said Portage devs have pushed through far > larger changes than anything we need -- look at the "use becoming useq" > behaviour changes, for example. Paludis does not require or want any > such large change, and we'd consider anything that required that to be > broken. use/useq change over occured well after the tree had been converted- it's actually a decent example of how to do the changeover- that was also a permenant change, not a "paludis is an alternative and we want to stick it in the tree". > | Feature introduction is done via introducing support, then sitting on > | it for ~6 months to ensure folks don't get bit by it- notable > | exception was virtuals/* metapkg, although the buttload of bugs from > | it is a demonstration of *why* this route must be taken. > > There is a difference between "changes that affect people not using the > newer package manager" and "changes that are only relevant to people > using the newer package manager". Anyone asking for features that will > lead to Portage breaking will be beaten with a spork. N profile inheritance breaks portage. You were saying? Yes it's needed (regardless of the manager), but the point was "don't expose users to sharp/pointy things without a good reason". > | This is also why eapi came about- faster introduction of > | compatibility breaking changes. > > Which, unfortunately, it doesn't really do, since ebuilds still have to > be filename and source compatible. There were far better ways this > could have been handled. Feel free to suggest them- since it's initial discussion, your comments on it haven't really progressed beyond "y'all did it badly", without naming a solution that works. EAPI has it's faults, but it *does* version the ebuild format (regardless of the tree format) to move forward, which was it's intention. Versioning the tree format is a related, but seperate issue. > | Snarky response aside, I read the src (note the env screwups I've > | pointed out, and the fact y'all don't sup
Re: [gentoo-dev] Paludis and Profiles
On Tue, May 16, 2006 at 03:56:38PM -0700, Brian Harring wrote: > If your parent parsing implementation handled N parents on a single > line (rather then parent per line as you do now), portage would > explode rather then silently use the left most. Your implementation > isn't doing that however... And that won't even work. Woot. About the only guranteed "portage will choke and not invalidly use N parent profiles if it doesn't support it are"- 1) specify the parents prefixed with #, fex # .. # ../blah End result is that python will throw a TypeError (might be ValueError). Not incredibly clean. 2) insane profile inheritance version trick. Require the leftmost parent to point at a custom profile, say profiles/version1, which has a nice little bashrc along the lines of die "upgade your $PKG_MANAGER- your current version cannot parse this profile properly". If the package manager knows of version1, it just filters that parent out as it goes- if it doesn't, any/all ebuild actions result in a forced bail as soon as control is transfered over to ebuild env. Both solutions suck, and the alternatives of "just ignore it" or "require left parsed profile to be minimally sane" don't cut it all that well. ~harring pgpTah70VvU9h.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Wed, May 17, 2006 at 12:11:34PM +0100, Stephen Bennett wrote: > On Wed, 17 May 2006 12:14:37 +0200 > Paul de Vrieze <[EMAIL PROTECTED]> wrote: > > > Using the normal profiles would also establish paludis as a possible > > replacement of portage as primary package manager. Refraining from > > doing so disqualifies paludis from becoming a replacement for > > portage. As the only point in adding a secondary package manager is > > the possible replacement of the current primary package manager, I > > see no point to make any paludis directed changes to the tree. > > Using the normal profiles isn't an option unless they're changed to > include virtual/portage in the system set instead of sys-apps/portage. > That's the key change we're interested in here -- that the system set > not pull in portage when paludis is being used instead. Override the virtuals via user side configuration (capabilities existant in portage) is one solution to that issue. ~harring pgpDVoa60vJds.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Wed, May 17, 2006 at 02:57:05PM +0100, Ciaran McCreesh wrote: > On Wed, 17 May 2006 12:04:33 +0200 Paul de Vrieze <[EMAIL PROTECTED]> > wrote: > | - Paludis must be able to handle a standard portage /var/db/pkg tree. > | This means that paludis can read it, and write it. Enabling mixing > | portage and paludis up to some degree. > > Paludis can read a Portage-generated VDB. Portage can't read a > Paludis-generated VDB, because Paludis has more features. What features? You're tracking CONFIG_PROTECT_*, and saving a copy of the eclass (icky solution, but we've discussed that in the past). Beyond that? > | - Paludis must work with all current ebuilds, > > Portage does not work with all current ebuilds. Name a few please, ones that are portage incompatibility rather then "ebuild no longer works against other ebuilds in the tree". Can't do anything about the latter, but the former without proof is fud. > | and support all features of portage. > > That's insane. Why should we support Portage-style 'candy' spinners? I'd expect he's talking more about stuff like having an ebuild binary/script for walking the phases of an ebuild for development. > | This includes recognition of EAPI > > Funnily enough, unlike Portage, Paludis has full EAPI handling. Please clarify on the "full"- since portage relies on EAPI protection already, any issues you see with it's implementation I'd love to know. > | and no renaming of the variables used. > > Why should Paludis emulate Portage internals that no-one uses? Moot issue, as I pointed out, dev-lang/perl (and others) are affected by it (so someone uses it). Additionally, you went and commited the vars into paludis (doing exactly what I said to do), thank you- lets avoid the 5 emails back and forth in the future however please... ~harring pgpAX6eJmmglI.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Wed, May 17, 2006 at 04:26:28PM +0100, Ciaran McCreesh wrote: > On Wed, 17 May 2006 17:11:04 +0200 Paul de Vrieze <[EMAIL PROTECTED]> > wrote: > | Let me clarify my statement. I don't care about candy spinners. > | Paludis (or any other package manager that is to be integrated into > | gentoo) should basically be able to allow a level of mix and match. > | This means that at the initial import, it can be run on any package > | instead of portage, and the results still be usable for portage > | (possibly after a conversion stage). > | > | This allows testing out the package manager. > > Not realistic. It means that any new package manager can't do anything > new. I'd also like to point out that you can't upgrade to a new Portage > version, install some things, downgrade to an older Portage version and > expect things to carry on working. Actually, you can for .54 and 2.1. The only issue is cache backend changeover, but that's minor (--metadata, or let portage regen on it's own). Paludis has to work with the ebuilds that are in the tree now- if it becomes official, go nuts, redefine the standards as you like, until then it needs to remain ebuild level compatible with portage. Yes it castrates some of the shineys, but portage suffers the same for any non-versioned change. > | > | - No part of the tree, except those that by nature are paludis > | > | specific, may require the usage of paludis instead of portage. > | > | This requirement can only be removed after a decision is made by > | > | the council to retire portage in favour of paludis. > | > > | > Again, insane. EAPI allows ebuilds using things that developers have > | > been after for years (you know, slot and use deps) to be in the > | > tree in such a way that they appear masked to Portage. That's a > | > large part of the point of EAPI. > | > | Let's make clear why I put this in. Basically I am of the opinion > | that until a decision is made to make (in this case) paludis the > | primary package manager, all official packages should work with > | portage. Package masked packages are not considered official. > > What of EAPI masked packages? > > The same situation will occur when newer Portage versions supporting > newer EAPIs are released into p.mask or ~arch. Some packages will end > up relying upon something that isn't the stable package manager. One concern here- EAPI was added to version the ebuild format- as such, *everyone involved* should be defining the new EAPI. Defining one in one project, and having it end up in the tree is a no go. Well aware I used EAPI="prefix" for the prefix branch, but that also was for testing. It has not, nor will it ever touch the tree till when it's agreed upon by folks also. ~harring pgpviUaPDES9p.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Wed, May 17, 2006 at 05:32:38PM +0100, Ciaran McCreesh wrote: > On Wed, 17 May 2006 11:23:19 +0200 Wernfried Haas <[EMAIL PROTECTED]> > wrote: > | We really should figure that stuff out before we start integrating an > | externally written package manager we have no influence on whatsoever > > How much influence does your typical Gentoo developer or user have over > the development of Portage? Please consider long-standing feature > requests such as :slot and [use] deps in your answer. Can we *please* avoid the portage bashing for at least a few days? As we've discussed in the past, sane base design and you can do use/slot without too much trouble. Folks *do* request things of portage, and it *does* get added- multilib came about via requests from lv (pretty quick turn around), axxo's need for env tricks to deal with /etc/profile issues* results in pre/post phase hooks being added, etc. Portage devs work with a crap source trying to implement what folks want- the code does fight certain features. That doesn't mean you can construe it as "portage devs don't listen" as you're implying. Besides that, lay off 'em. Lot of people want features out of portage, but nobody ever steps up- usually what comes of it is just someone flaming them, rather then providing a patch. ~harring pgpVt8aP1lkMN.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Wed, May 17, 2006 at 07:44:16PM +0100, Ciaran McCreesh wrote: > On Wed, 17 May 2006 11:13:09 -0700 Brian Harring <[EMAIL PROTECTED]> > wrote: > | > Paludis can read a Portage-generated VDB. Portage can't read a > | > Paludis-generated VDB, because Paludis has more features. > | > | What features? You're tracking CONFIG_PROTECT_*, and saving a copy > | of the eclass (icky solution, but we've discussed that in the past). > | > | Beyond that? > > Right now, the biggie is virtuals. Attempting to unmerge a virtual that > was installed via Paludis will confuse the heck out of Portage. There's > also the whole "handling symlink / directory mismatches" issue, which > will cause Portage to incorrectly unmerge some Paludis-installed things > (and, for that matter, some Portage-installed things). Clarify on virtuals please. Unless you're mangling the data for sym/dir, that's an unmerge time decision (as such it's not vdb data specific). > | > | - Paludis must work with all current ebuilds, > | > > | > Portage does not work with all current ebuilds. > | > | Name a few please, ones that are portage incompatibility rather then > | "ebuild no longer works against other ebuilds in the tree". Can't do > | anything about the latter, but the former without proof is fud. > > We went over this already. Remember webapp.eclass? Nope. Assume I'm stupid, don't ask a question when I ask for an answer, just state it please- saves both you and I time. Do recall they were triggering merge -C calls on their own, but that's not portage incompatibility as much as doing something dumb... > | > | and support all features of portage. > | > > | > That's insane. Why should we support Portage-style 'candy' spinners? > | > | I'd expect he's talking more about stuff like having an ebuild > | binary/script for walking the phases of an ebuild for development. > > Heh. You keep on picking out things that you think will be difficult to > implement. Ebuild is easy- I'm pointing at it because the local env issue should rear it's head there. It's also a tool that ebuild devs rely on fairly heavily for debugging, as such two birds one stone (locals issue you get to investigate closer, and you flesh paludis out further). > | > | This includes recognition of EAPI > | > > | > Funnily enough, unlike Portage, Paludis has full EAPI handling. > | > | Please clarify on the "full"- since portage relies on EAPI protection > | already, any issues you see with it's implementation I'd love to know. > > Portage still relies upon being able to source ebuilds, even if their > EAPI isn't supported. Paludis doesn't? Related, doc this stuff out please. Portage differences doc you've got is more "we're better cause of xyz"- which is fine, but a low level "this is what we do differently" (metadata/security fex) would at least allow the possibility of folks being on the same page. > | Additionally, you went and commited the vars into paludis (doing > | exactly what I said to do), thank you- lets avoid the 5 emails back > | and forth in the future however please... > > Yes, we now have ~15 lines of useless code. But if that's what it takes > to make you happy... Makes that perl patch behave properly for security bug, so yes, it's progress- thank you. ~harring pgpeVgMBjRfMo.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Wed, May 17, 2006 at 08:50:32PM +0100, Ciaran McCreesh wrote: > On Wed, 17 May 2006 12:06:09 -0700 Brian Harring <[EMAIL PROTECTED]> > wrote: > | Clarify on virtuals please. Unless you're mangling the data for > | sym/dir, that's an unmerge time decision (as such it's not vdb data > | specific). > > We're faking new-style virtuals for old-style virtuals, so things end > up in vdb that don't have an associated 'real' ebuild. Portage can't > unmerge them, and it has some trouble with the reduced-content entries > for these too. Instead of on the fly generation of the virtuals pkgs (as pkgcore/portage do), you've flattened them into an actual on disk vdb entry? Re: incompatibility, that can be dealt with by generating a fake ebuild- already generate an env from the looks of it (not seeing anything in RDEPEND/DEPEND however). > | > We went over this already. Remember webapp.eclass? > | > | Nope. Assume I'm stupid, don't ask a question when I ask for an > | answer, just state it please- saves both you and I time. > | > | Do recall they were triggering merge -C calls on their own, but > | that's not portage incompatibility as much as doing something dumb... > > And that's exactly it. At what point does something stop being API and > start being "someone is doing illegal things with internals"? Common sense. Paludis wouldn't like what they were doing any more then pkgcore nor portage- modification of a node cannot cause unstated dependency changes, what they were doing was going outside the constant metadata rules binding all ebuild supporting pkg managers (well, the ones that don't want the 100-400x hit from lacking a metadata cache at least). A real example of where portage doesn't support an ebuild in the tree would be welcome (as stated, if it exists it needs fixing). > | Ebuild is easy- I'm pointing at it because the local env issue should > | rear it's head there. It's also a tool that ebuild devs rely on > | fairly heavily for debugging, as such two birds one stone (locals > | issue you get to investigate closer, and you flesh paludis out > | further). > > Actually, I was planning to handle that one by BREAK_FUNCTIONS (name > sucks and is not final), which is kinda like SKIP_FUNCTIONS but rather > than skipping, launches an interactive shell. Did something similar with ebuild-shell- folks for the most part liked it. Meanwhile... get cracking, you'll see far more local assumptions transitioning between phases then transitioning between groupped merge phases -> groupped unmerge phases > | > Portage still relies upon being able to source ebuilds, even if > | > their EAPI isn't supported. > | > | Paludis doesn't? > > Nope. Paludis can sanely (as in, treat as EAPI masked) handle ebuilds > that bash can't parse. This paves the way for XML-based ebuilds, which > as we all know is a critical feature required for enterprise support. 'Cept EAPI was specifically targeted at bash based ebuilds only. Alternative formats (non bash fex), expected folks to solve that issue themselves (since I didn't see a sane general solution to it). For what EAPI is defined as, portage supports it fully. > | Related, doc this stuff out please. Portage differences doc you've > | got is more "we're better cause of xyz"- which is fine, but a low > | level "this is what we do differently" (metadata/security fex) would > | at least allow the possibility of folks being on the same page. > > Yeah, that's something that would be useful. I was trying to get spb to > do it... I'd suggest it as priority- it's really not all that fun arguging over details lifted from scanning the code, and getting into terminology wars. Get the doc up, folks can evaluate what the actual support costs for paludis are vs assumptions/guesses. ~harring pgpBtBoz8DPTx.pgp Description: PGP signature
