Re: [gentoo-dev] Gentoo's problems
On Friday 16 March 2007 18:58, Luca Barbato wrote: > Jason Stubbs wrote: > > That's not entirely true. The main trouble with refactoring portage code > > is that there is no defined public API and so even the littlest changes > > are likely to break things in gentoolkit and several of the portage gui > > front end packages. > > What about branching, doing the dirty stuff and let others fix their code? I've worked on a branch in the past as has Brian and a lot of the code that went into 2.1.0 was done in a seperate branch. However, a lot of bugs that got fixed in the release branch never got fixed in the development branches and so switching wasn't really viable. For 2.1.0, a lot of the work that was done ended up being completely redone in the release branch. In hindsight, if the team had have worked together as a team on a dev branch and only critical bug fixes went into the release branch while the dev branch was being readied it would have worked. Proper coordination would be needed but I guess it still could... -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gentoo-dev vs lkml?
Rearranging and snipping a bit to clarify my points. On Friday 16 March 2007 09:17, Daniel Drake wrote: > Jason Stubbs wrote: > > 2) Each technical area usually has a clear authority - ie. a spokesman > > whom is listened to and usually has one's posts challenged with clear > > respect. > > 1) There is a fairly clear chain of command. [between those technical areas] > I've seen a few people make this kind of comment recently, and I'm never > sure whether they mean it as it sounds or not. > > What I think people mean to say is that for the major subsystems, there > is a fairly clear structure to the technical contribution flow and the > review process. But there is also a huge amount of code which is not > 'maintained' in this way, where the only realistic patch-target is > Andrew Morton, the lead maintainer of the whole kernel. This is exactly what I meant. > But in my opinion this structure doesn't really relate to the flaming. > > I don't really understand how this relates to the question why linux > kernel flamewars don't appear to harm the kernel community in the way > that gentoo-dev flamewars appear to harm the Gentoo community. Andrew Morton doesn't get involved in the flamewars. From what I've seen, his responses are usually "I don't understand why you are doing this so please explain further", "I think doing it this way would be better than doing it that way" and "I need this, this and this before this patch can move forward". I imagine things work mostly the same in the seperable subsystems too. How does that relate to the difference in flamewar harm? I think that the transparent workflow makes it easy to see that the flamewars have relatively little effect on the amount achieved. I also think that the workflow helps assure users that the flamewars don't affect the end product other than to perhaps delay some specific feature. > Here are my thoughts, and I think there are several answers here: Both very good points. > I also feel that the community is more mature, in that people truly with > a grasp on the community generally do not get involved with the heated > discussions when they go beyond the point of technical review. By this I > mean simply: people don't have the apparent urge to respond to mails in > the way that people do here -- kernel developers don't seem to take bait > from trolls. This was what I was trying to get at in the 3rd point of my first email. I probably shouldn't have lumped it under "paid devs", eh? The "urge to respond" problem is probably one of our biggest downfalls here. Not only in taking flamebait though. It is also in replying to a thread that is not really in one's domain - devs acting like users reading uninformed press coverage, if you will. > In general threads also seem to stay on topic more than they do here as > well. Steve Long's initial reply to the thread here didn't add anything > to the discussion Grant was trying to start, and he even admitted so! > I'd say on the LKML replies like this generally don't happen, or if they > do, they get 0 responses. Also part of the "maturity" point. Perhaps we all just need to grow up? ;) > Another factor: think about the level of ratio of developers to users on > both lists. Even if most posts here are by developers, there are a > comparatively large number of non-developer readers, plus the > discussions make good reading material linked from the GWN and forums etc. > > Now look at the LKML. It's often hard to find general discussion behind > the truckloads of patches and river of technical review emails. A large > proportion of the content is not "understandable" unless you have a good > knowledge of C, operating systems, and the technical area in question. > This isn't a place that users hang out, users dont really read it > either, and you need to be a decent developer to get involved in the > first place. This is an important point that I hadn't considered. It kind of resembles the affect of bad press coverage you mentioned earlier. I'm not sure that there's much that can be done about it though - at least not in the short term. Perhaps a code of conduct should be created that discusses how one should behave rather than how one should not. Taking cues from member of LKML that show maturity as well as other communities that do well, it could cover what is expected in the situations where we are failing and extended as needed. What do you think? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo's problems
On Friday 16 March 2007 02:47, Ciaran McCreesh wrote: > On Thu, 15 Mar 2007 18:40:05 +0100 Jakob Buchgraber > > <[EMAIL PROTECTED]> wrote: > > So why don't you start rewriting, refactoring and improving the > > portage source? It definitely doesn't make sense to create a > > competing package management system. > > Because it's far simpler to start from scratch. Refactoring is only > possible if the initial design is at least vaguely sane. With things as > they are now, making a change is nigh on impossible because there's no > way of evaluating the impact. That's not entirely true. The main trouble with refactoring portage code is that there is no defined public API and so even the littlest changes are likely to break things in gentoolkit and several of the portage gui front end packages. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gentoo-dev vs lkml?
On Thursday 15 March 2007 00:59, Grant Goodyear wrote: > Underlying the draft code of conduct is an assumption that aggressive > and less-than-nice behavior on gentoo-dev is seriously harming Gentoo. > On the other hand, LKML is famous for its flamewars, and nobody claims > that Linux is in serious trouble. Does anybody have a good feeling for > where the difference lies? The main differences I see are: 1) There is a fairly clear chain of command. 2) Each technical area usually has a clear authority - ie. a spokesman whom is listened to and usually has one's posts challenged with clear respect. 3) Many contributors are paid to do it and thus have the time to spend isolating the technical merits of a post from the flames or, more importantly, time to develop a work ethic that allows that to do such separation habitually. > Are we sure that we're solving the right problem? (That's not a rhetorical > question; I really don't know the answer.) Good question. I wouldn't have a clue as to the best resolution either. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Some council topics for March meeting
On Sunday 04 March 2007 02:05, Ciaran McCreesh wrote: > On Sun, 4 Mar 2007 01:51:39 +0900 Jason Stubbs <[EMAIL PROTECTED]> > > wrote: > > There were two separate specifications - glep42 and multiple > > repositories - that should have been discussed seperately. On a > > seperate thread, Marius said something to the effect of "specs are > > much easier to extend than to alter". Having read that, I think we > > were both wrong - specification of a repository should probably have > > been left out completely until repositories had been hashed out. > > Which is what I was pushing for all along. I was trying to leave > multiple repositories entirely out of it -- despite Paludis making use > of them -- because the GLEP had nothing to do with multiple > repositories. I don't remember the specifics, but I remember that there was something that didn't seem to go along with our vision. But yes, I do remember you pushing for keeping multiple repositories out of it. In general I try to look at everything as my fault (ie. what could I have done different?) and in that case I probably should have moved to remove whatever it was that didn't sit right rather than pushing to have it adjusted to my vision. > > To sidetrack just a little more, I think this illustrates one of the > > reasons why having PMS (aka EAPI-0 spec) completed is so important. > > Not only would it allow for Gentoo package manager(s) to be > > interchanged/replaced, it would provide a incontrovertible context > > for discussion of new features. > > There aren't going to be any new features in PMS. The only package > manager changes that we want to come about as a result of it are bug > fixes. Yep and that's a good thing. > Incidentally... Side note on PMS vs EAPI-0: the way PMS is written, > it's deliberately very easy to integrate EAPI-1, EAPI-2 or whatever > into the document. Consider PMS to be a document that is capable of > holding all EAPIs, with EAPI-0 being the only one that's actually there > for now. Once EAPI-1 is agreed upon, it can be added to PMS rather than > having to be a whole new document. That also sounds like a good thing as it gives new ebuild authors a single authoritative source on what to expect from a package manager. Although EAPI-0 will still be defined, even if it is only as "revision XYZ of PMS". Also, as a leading dev to a (for a? on a? i've spent too long in Japan :/) "not an official Gentoo project" package manager, I hope you realize the danger of not having explicit versions of the document. Take, for example, the lack of acceptance of some changes to the dev guide that have been somewhat controversial... > > This is really irrelevant. It's not matter of "if" he gets access but > > only as to "when". After the initial work is done and the team is > > ready to go public all his "noise" will come out. I can only think of > > two choices here: 1) whether you and he both continue to be visceral > > or instead try to build a good working relationship; and > > 2) whether you discuess any issues with the spec now or when it goes > > public. > > That's a fairly big difference. If it's later on, there won't be lots > of holes that we know are there that he can use as some kind of twisted > proof that PMS sucks. That's a "yep" again to it being a fairly big difference although I won't back your justifications. It's something you as a team and ultimately Stephen needs to decide. Either way, I'm just reminding all that you're not preventing Brian from having a say. Anyway.. Unless your reply has either something that I don't agree with or that is really exciting, I'll let you have the last say. (Why is it that those that are technically minded always want to have the last say? ;) -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Some council topics for March meeting
On Saturday 03 March 2007 23:14, Ciaran McCreesh wrote: > On Sat, 3 Mar 2007 05:57:35 -0800 Brian Harring <[EMAIL PROTECTED]> > > > Two angles on the behaviour BS; either related to the fact I'm dead > > set on the spec reflecting portage behaviour, and being finished, or > > it's related to the fact the paludis devs generally speaking would be > > the first group of folks lining up to kick me in the balls. To Ciaran: even though my following statements could be considered retorts, I'm not agreeing or disagreeing with the above. > No, it's that you're dead set on derailing it and being as unhelpful as > possible. My experience with Brian has always been that he's genuinely intent on being helpful. The issue, I would think, is that you find is manner (as illustrated by the above quote) to be irritating. That leads to his intention of helping to being unrealized. For the record, I've found his manner irritating at times in the past as well, although arguments have always been limited to IRC. > You have absolutely nothing to contribute, As Alec mentioned, Brian definitely has a lot to offer in terms of knowledge. > as evidenced by every previous time you've gotten involved with anything > I've done, and given how badly you tried to screw up GLEP 42 and how much > of my time you wasted doing so, I'm not sure about other instances. There seems to be a lot that I didn't see - perhaps on IRC? But if I recall the mailing list discussions correctly, if anybody can be accused of trying to derail it that person would be me. However, I wasn't trying to derail it. As with Brian and yourself above, I found your manner to be irritating which led to my intent on being helpful being unrealized. It might be helpful to the current discussion of PMS so I'll go a little into what I think went wrong there. You had an idea of how multiple repositories would function as did myself and Brian (the two most active portage devs at the time). These ideas were developed independently and neither were implemented or even rfc'd. There were two separate specifications - glep42 and multiple repositories - that should have been discussed seperately. On a seperate thread, Marius said something to the effect of "specs are much easier to extend than to alter". Having read that, I think we were both wrong - specification of a repository should probably have been left out completely until repositories had been hashed out. To sidetrack just a little more, I think this illustrates one of the reasons why having PMS (aka EAPI-0 spec) completed is so important. Not only would it allow for Gentoo package manager(s) to be interchanged/replaced, it would provide a incontrovertible context for discussion of new features. > I really don't want to deal with your noise ever again. I'll address this in my last "retort". > You also have a lot to gain by wrecking the process, Quite the contrary. Brian is in exactly the same position as you - other than having a representative of his project helping to prepare PMS (unless these threads have misled me). Any loss you suffer from not having a complete EAPI-0 specification is his loss too. > and your past behaviour has shown that you'll stoop to any kind of dirty > trickery and abuse of the system that you think you can get away with > rather than having a proper technical discussion. > > Frame it any way you want, but so far as I'm concerned there is nothing > of value you can possibly provide that would make up for the headache > of having to handle your own unique form of input. > > But hey, it's up to spb, not me. Try emailing him if you want access. I > couldn't give you svn access even if I wanted to. This is really irrelevant. It's not matter of "if" he gets access but only as to "when". After the initial work is done and the team is ready to go public all his "noise" will come out. I can only think of two choices here: 1) whether you and he both continue to be visceral or instead try to build a good working relationship; and 2) whether you discuess any issues with the spec now or when it goes public. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Reliance upon || ( use? ( ) ) behaviour
On Saturday 24 February 2007 13:17, Ciaran McCreesh wrote: > On Sat, 24 Feb 2007 13:09:40 +0900 Jason Stubbs <[EMAIL PROTECTED]> > | Okay, I must be missing something here. If package foo can work with > | either bar or baz equily as well but not both, why should it force an > | artificial preference? > > For consistency. Installing a package with identical USE flags should > give the same result on all systems. > > | Also, if packages should not specify dependencies based on what is > | installed, the semantics of || ( ) would need to be changed such that > | the first non-masked packages is always installed. > > No, || ( ) has legitimate use for switchable dependencies. For example, > if a package can use either curl or wget, and it can switch at runtime, > RDEPEND="|| ( curl wget )" is fine. Similarly, if a package needs > either tetex or ptex at compile time, DEPEND="|| ( tetex ptex )" is > correct. > > | The only reason I can see for the above is to be able to have > | non-broken binary packages. However, that can be addressed by > | replacing *DEPEND in binary packages with their resolved forms. > > If it affects binaries, it needs to be a USE flag. So with your DEPEND="|| ( tetex ptex )" case, you're saying that it is valid because the choice of tetex or ptex doesn't affect the resultant binaries? Extrapolating that, specifying link dependencies within an || construct is flat out wrong? If so, it's way out of my domain so I can't really comment other than you haven't given a reason for this requirement. Having said that, I'll accept it if we're strictly talking in the EAPI-0 domain as there is no way for a package manager to guarantee a safe --depclean implmentation given that raw *DEPENDs are stored in the current installed package database. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Reliance upon || ( use? ( ) ) behaviour
On Saturday 24 February 2007 12:34, Ciaran McCreesh wrote: > On Sat, 24 Feb 2007 12:27:35 +0900 Jason Stubbs <[EMAIL PROTECTED]> > > wrote: > | For the 14 cases you mentioned that were making a mistake, they > | probably can be rewritten so as to force an install of the first > | matching package, but when that isn't what is wanted it becomes a bit > | of a headache. > > That should *always* be what's wanted. Packages should only alter > dependencies / build parameters based upon USE flags, not based upon > what else happens to be installed. Okay, I must be missing something here. If package foo can work with either bar or baz equily as well but not both, why should it force an artificial preference? Also, if packages should not specify dependencies based on what is installed, the semantics of || ( ) would need to be changed such that the first non-masked packages is always installed. The only reason I can see for the above is to be able to have non-broken binary packages. However, that can be addressed by replacing *DEPEND in binary packages with their resolved forms. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Reliance upon || ( use? ( ) ) behaviour
On Saturday 24 February 2007 03:57, Ciaran McCreesh wrote:
> On Fri, 23 Feb 2007 22:56:19 +0900 Jason Stubbs <[EMAIL PROTECTED]>
>
> wrote:
> | Disallowing it would be the cleaner in terms of package manager
> | responsibilities, but ...
>
> Well, I looked through the tree.
>
> There is exactly one package using this construct that doesn't get it
> wrong. That package is openoffice, and it uses it to do this:
>
> java? ( || ( !amd64? ( =virtual/jdk-1.5* ) =virtual/jdk-1.4* )
> dev-java/ant-core )
The openoffice example above shouldn't need the !amd64? condition unless
the amd64 port of openoffice itself doesn't work with a jdk-1.5 package.
However, if the amd64 port does in fact not work with jdk-1.5, the only
way to rewrite without losing functionality would be:
amd64? ( =virtual/jdk-1.4 )
!amd64? ( || ( =virtual/jdk-1.5* =virtual/jdk-1.4* ) )
> The other fourteen packages using it are either making the mistake
> described in the original email in the thread, or using it where no use
> flag is required at all.
>
> Given that the one legitimate case can easily be rewritten in another
> way with no loss of functionality, is there really a justification for
> keeping this?
The only compelling reason is aesthetic(sp?). Kevin Quinn rewrote the
example given in ebuild(5) but in doing so functionality was lost.
To rewrite it without any change in behaviour would require something like
below.
For the 14 cases you mentioned that were making a mistake, they probably can
be rewritten so as to force an install of the first matching
package, but when that isn't what is wanted it becomes a bit of a headache.
|| (
sdl? ( media-libs/libsdl )
svga? ( media-libs/svgalib )
opengl? ( virtual/opengl )
ggi? ( media-libs/libggi )
virtual/x
)
becomes:
sdl? (
svga? (
opengl? (
ggi? (
|| ( media-libs/libsdl media-libs/svgalib virtual/opengl
media-libs/libggi virtual/x )
)
!ggi? (
|| ( media-libs/libsdl media-libs/svgalib virtual/opengl
virtual/x )
)
)
!opengl? (
ggi? (
|| ( media-libs/libsdl media-libs/svgalib media-libs/libggi
virtual/x )
)
!ggi? (
|| ( media-libs/libsdl media-libs/svgalib virtual/x )
)
)
)
!svga? (
opengl? (
ggi? (
|| ( media-libs/libsdl virtual/opengl media-libs/libggi virtual/x )
)
!ggi? (
|| ( media-libs/libsdl virtual/opengl virtual/x )
)
)
!opengl? (
ggi? (
|| ( media-libs/libsdl media-libs/libggi virtual/x )
)
!ggi? (
|| ( media-libs/libsdl virtual/x )
)
)
)
)
!sdl? (
svga? (
opengl? (
ggi? (
|| ( media-libs/svgalib virtual/opengl media-libs/libggi virtual/x )
)
!ggi? (
|| ( media-libs/svgalib virtual/opengl virtual/x )
)
)
!opengl? (
ggi? (
|| ( media-libs/svgalib media-libs/libggi virtual/x )
)
!ggi? (
|| ( media-libs/svgalib virtual/x )
)
)
)
!svga? (
opengl? (
ggi? (
|| ( virtual/opengl media-libs/libggi virtual/x )
)
!ggi? (
|| ( virtual/opengl virtual/x )
)
)
!opengl? (
ggi? (
|| ( media-libs/libggi virtual/x )
)
!ggi? ( virtual/x )
)
)
)
--
Jason Stubbs
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Reliance upon || ( use? ( ) ) behaviour
On Friday 23 February 2007 06:18, Ciaran McCreesh wrote: > On Thu, 22 Feb 2007 22:05:56 +0100 Thomas de Grenier de Latour > > <[EMAIL PROTECTED]> wrote: > | On Thu, 22 Feb 2007 19:08:48 +, Ciaran McCreesh > | > | <[EMAIL PROTECTED]> wrote: > | > As has been discussed in the past, the only correct way of handling > | > this from an ebuild perspective is lots of use && has_version calls > | > | Which sounds like trying to mimic whatever the deps solver logic may > | have been, no? So, why not just let the dep solver itself give the > | right answer to the ebuild? It could well set a resolved DEPEND > | variable (lets call it $RESOLVED_DEPEND for instance) in the ebuild > | env, that one could query with some helper functions. This is the best solution that I could come up with in the past as well. > That strikes me as another large complication. Something that > complicated shouldn't be necessary. > > Also, I'd like an EAPI-0-able solution :) Disallowing it would be the cleaner in terms of package manager responsibilities, but ... > | > So, is there a legitimate reason for this complication to exist? Or > | > should use? blocks being direct children of || ( ) be forbidden? > | > | It's not clear to me what would be your prefered DEPEND syntax for the > | ebuild(5) example you've quoted. Something like this maybe?: > | sdl? ( media-libs/libsdl ) > | !sdl? ( > | svga? ( media-libs/svgalib ) > | !svga? ( > | ... > | > | (which is not really equivalent) > > Right. It's not the same, but it's a lot more logical. the above code - while likely to be what the ebuild author was originally intending when using the "|| ( use? () )" - is not very readable or maintainable. There's also one other issue that you didn't mention in your original email. If an ebuild has "|| ( foo? ( foo/pkg ) bar? ( bar/pkg ) )" and neither foo or bar are set, should it be an error because there was no successful result among the possibilities? While my gut feeling says "yes" and (I think) portage currently says "no", I can't really see any strong reason for either case. Disallowing use clauses directly beneath || constructs would completely sidestep that issue too. ;) But I still what TGL described even if only for EAPI-1 or beyond... -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Dependencies on system packages
On Sunday 17 December 2006 16:04, Ciaran McCreesh wrote: > On Sun, 17 Dec 2006 15:10:57 +0900 Jason Stubbs <[EMAIL PROTECTED]> > wrote: > | I've tried to be objective here so if my viewpoint isn't obvious I'll > | state it outright. I think all packages should depend on every > | package that they need to build and/or run. Whether this is done > | explicitly or with meta-packages, I don't really care. The only > | reason for not being explicit with deps is to cater for old sloppy > | versions of portage. Unless there are other reasons not stated here? > > If you mandate that, any package using autotools will need around fifty > new entries in DEPEND. There's ways to manage this complexity, such as putting the dependencies into autotools' RDEPEND (if it can be considered correct) or by using meta-packages. However, your point is against requiring that packages _must_ specify all system dependencies. While I personally believe that packages should specify all dependencies, what I'm arguing against is requiring that packages _must not_ specify any system dependencies. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Dependencies on system packages
On Sunday 17 December 2006 10:27, Alec Warner wrote: > If your package is 'not important' meaning it will never be in 'system' for > any profile, you should not depend on anything in 'system', as stuff in > system should already be installed in a given (sane) configuration. Except if the package is fussy on what version it needs. > If your package may be in 'system' in a given profile, you need to ensure > your package builds in the proper order, with regards to other system > packages. The classic example is zlib; if you need zlib to uncompress > something, then you should put zlib in the deps; that way when someone is > building say, a stage1, your package will build after zlib, instead of > before it. Given your point above, this should only be important as far as bootstrapping goes. After bootstrapping, "stuff in system should already be installed". However, 'system' becomes quite an extensive list of packages after enabling all use flags that didn't begin with 'no'. I've attached the list that results from my current tree. So are packages such as qt, nvidia-drivers, courier-imap, samba and jack-audio-connection-kit also part of 'system' or is 'system' only limited to the profile-defined USE flags at the time of bootstrapping? > You have to be careful in deciding what to specify, as doing things > incorrectly in this case can often cause dependency loops which are > sometimes fun to debug; perl and openssl were infamous back in the day for > this. This stopped applying with recent versions of portage. I'm pretty sure the current stable version of portage detects circular deps and tries to resolve them utilizing installed packages but I've lost track of what's made it to stable and what hasn't. As far as I know, both palidus and pkgcore do or will also support this, so your point here doesn't hold. > Enterprising users would specify the 'doc' useflag. openssl requires perl > to generate its docs and perl requires openssl for some encryption stuff. [snipped] This example is not a reason to leave out appropriate dependencies. I've tried to be objective here so if my viewpoint isn't obvious I'll state it outright. I think all packages should depend on every package that they need to build and/or run. Whether this is done explicitly or with meta-packages, I don't really care. The only reason for not being explicit with deps is to cater for old sloppy versions of portage. Unless there are other reasons not stated here? -- Jason Stubbs app-admin/eselect-1.0.2 app-admin/eselect-esd-20060719 app-admin/eselect-opengl-1.0.3 app-admin/gamin-0.1.7 app-admin/perl-cleaner-1.04.3 app-admin/php-toolkit-1.0-r2 app-admin/skey-1.1.5-r5 app-admin/syslog-ng-1.6.9 app-arch/bzip2-1.0.3-r6 app-arch/cpio-2.6-r5 app-arch/gzip-1.3.5-r10 app-arch/rpm-4.4.6-r3 app-arch/rpm2targz-9.0-r5 app-arch/tar-1.16-r2 app-arch/unzip-5.52-r1 app-crypt/gnupg-1.4.6 app-crypt/gnupg-1.9.21 app-crypt/hashalot-0.3-r2 app-crypt/kth-krb-1.2.2-r2 app-crypt/mhash-0.9.2 app-crypt/mit-krb5-1.4.3-r3 app-crypt/opencdk-0.5.5 app-doc/doxygen-1.4.7 app-doc/opengl-manpages-20001215 app-doc/php-docs-20050822 app-editors/emacs-21.4-r4 app-misc/ca-certificates-20050804 app-misc/mime-types-5 app-misc/pax-utils-0.1.13 app-portage/portage-manpages-20060913 app-portage/portage-utils-0.1.20 app-shells/bash-3.1_p17 app-text/aspell-0.50.5-r4 app-text/build-docbook-catalog-1.2 app-text/docbook-dsssl-stylesheets-1.79 app-text/docbook-sgml-dtd-3.0-r3 app-text/docbook-sgml-dtd-3.1-r3 app-text/docbook-sgml-dtd-4.0-r3 app-text/docbook-sgml-dtd-4.1-r3 app-text/docbook-sgml-dtd-4.2-r2 app-text/docbook-sgml-utils-0.6.14 app-text/docbook-xml-dtd-4.1.2-r6 app-text/docbook-xml-dtd-4.2-r1 app-text/docbook-xml-simple-dtd-1.0-r1 app-text/docbook-xml-simple-dtd-4.1.2.4-r2 app-text/docbook-xsl-stylesheets-1.68.1-r1 app-text/ghostscript-gpl-8.54 app-text/htmltidy-4.8.6 app-text/jadetex-3.13-r1 app-text/libpaper-1.1.20 app-text/openjade-1.3.2-r1 app-text/opensp-1.5.2-r1 app-text/poppler-0.5.3 app-text/recode-3.6-r2 app-text/rman-3.2 app-text/scrollkeeper-0.3.14-r2 app-text/sgml-common-0.6.3-r4 app-text/tetex-3.0_p1-r3 app-text/xmlto-0.0.18 dev-db/cdb-0.75-r1 dev-db/firebird-1.5.3-r1 dev-db/freetds-0.62.3 dev-db/libiodbc-3.51.2 dev-db/libpq-8.0.8 dev-db/mysql-5.0.26-r1 dev-db/postgresql-8.0.8 dev-db/qdbm-1.8.70-r1 dev-db/qt-unixODBC-3.3.6 dev-db/sqlite-2.8.16-r4 dev-db/sqlite-3.3.5-r1 dev-db/unixODBC-2.2.11-r1 dev-dotnet/libgdiplus-1.1.13.2 dev-java/blackdown-jdk-1.4.2.03-r12 dev-java/java-config-1.3.7 dev-java/java-config-2.0.30 dev-java/java-config-wrapper-0.12-r1 dev-java/java-sdk-docs-1.4.2 dev-java/java-sdk-docs-1.5.0-r1 dev-java/sun-jce-bin-1.5.0 dev-java/sun-jdk-1.5.0.08 dev-lang/lua-5.0.2 dev-lang/mono-1.1.13.8.1 dev-lang/ocaml-3.09.2 dev-lang/perl-5.8.8-r2 dev-lang/php-5.1.6-
Re: [gentoo-dev] ACCEPT_LICENSE revisited
On Sunday 19 November 2006 06:25, Brian Harring wrote: > Left out that if it's unset, it should default to ACCEPT_LICENSE=* , > meaning no license filtering. [...] > > Backwards Compatibility > > === > > > > There should be no change to the user experience without the user > > explicitly choosing to do so. This mandates that the > > configuration variable be named ``ACCEPT_LICENSE`` as some users may > > already have it set due to ebuilds using ``eutil.eclass``'s > > implementation. It also mandates that the default ``ACCEPT_LICENSE`` be > > set to [EMAIL PROTECTED] in the main gentoo repository as there will > > be no internal default in portage. > > The current default in portage however is that of ACCEPT_LICENSE=*; > since portage doesn't yet filter on licenses, and since interactive > ebuilds already exist, _that_ is the default. > > Finally, NON-INTERACTIVE shouldn't be a license group; > RESTRICT=interactive is the route there; you can have gpl software > distributed on cds that must be interactive (feed cds in as > requested). > > The only solution there would to be to invent a fake license group for > it and tag it in... which is not what license is about. > > Interactivity is a seperate thing from license; keep it that way. You're missing the point. It is nothing to do with interactivity. It is to do with check_license and ebuilds for packages that must have their license explicitly accepted. In other words there should be no "*" and the default ACCEPT_LICENSE should default to everything except ebuilds that are currently using check_license. The NON-INTERACTIVE group specified in the original GLEP specified that set. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Ignoring/overwriting IUSE from an eclass
On Monday 06 November 2006 17:55, Ciaran McCreesh wrote: > On Wed, 8 Nov 2006 02:18:41 +0000 Jason Stubbs <[EMAIL PROTECTED]> > > wrote: > | Yes, I'm also sick of this negative level of civility. If I don't > | preempt it now, I'll likely be told that I'm taking the above two > | quotes out of context > > Which you are, since you removed a large part of my answer and then > used it to claim that my answer was unhelpful. Hint: read all of what I > wrote. I didn't claim that you were unhelpful; I merely claimed that you weren't civil. In fact, I acknowledged that your responses could be learned from. > | Ciaran's analogies are always outrageous, condescending and greatly > | accentuated. > > And a lot of people find them a pleasant change from the usual lack of > style and humour exhibited on this list. Effective technical writing > does not have to be boring. Sure, but others just find them to be uncivil personal attacks. > | Specifically, his intention is never to help the person > | he is replying to, but rather to show them that they are wrong. > > The person is irrelevant. What matters is whether someone looks at a > proposed incorrect solution and uses it. > > | He believes that is purely up to the person that he is replying to > | whether they learn from it or not. > > Well yes. What is this, nursery school? Keep these two points in mind. > | discussing it further won't help any. > > But you still felt the need to try to throw in a cheap shot full of > personal attacks. Right. My intention was only to present the facts as I see them so as to reassure Ryan Hill that he is not alone. I can understand why you might take offense, but I was no more throwing in "a cheap shot full of personal attacks" than you do with your analogies. I thought that there might be a slim chance that you'd learn from what I said, but I left that decision up to you - after all, this isn't nursery school. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Ignoring/overwriting IUSE from an eclass
On Monday 30 October 2006 17:44, Piotr Jaroszyński wrote:
> E_IUSE=${E_IUSE//"X"}
>
> But that's a dirty portage-specific hack ;]
On Monday 30 October 2006 18:43, Ciaran McCreesh wrote:
> Your solution is approximately on par with fixing a wobbly chair by
> sawing off all four legs and then attaching what's left to a crocodile.
On Monday 06 November 2006 03:36, Ryan Hill wrote:
> I'm sorry, but is anyone else sick and disgusted with Ciaran talking to
> people like this? This isn't called for and shouldn't be tolerated.
Yes, I'm also sick of this negative level of civility. If I don't preempt it
now, I'll likely be told that I'm taking the above two quotes out of context
and that I'm just spreading FUD, but I don't believe the context really
changed from the outset.
Ciaran's analogies are always outrageous, condescending and greatly
accentuated. Specifically, his intention is never to help the person he is
replying to, but rather to show them that they are wrong. He believes that is
purely up to the person that he is replying to whether they learn from it or
not. There's a 100+ comment bug about this, though, which ended up with his
dismissal so discussing it further won't help any.
--
Jason Stubbs
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Missing: Universal-CD - Gentoo discriminates shell and networkless users
On Tuesday 10 October 2006 03:45, Kari Hazzard wrote: After writing the last response, another thought came to mind that I figured I should post - and should probably be set out in a "user's guide to posting on dev mailing lists". I had the thought that users likely feel that it's okay to repeatedly post arguments for their point of view because they often see developers doing it. There is a very obvious parallel between users and developers in these threads in that both are lazy and thus want things done their own way in order to make their lives easier. The important difference is that (usually :/) at least some of the developers of each point of view are willing to implement the whole lot themselves. What they are arguing about is how much effort they see will be needed in the long term. Even in the case where a developer with a conflicting point of view is not willing to do the work now, the developer will argue for the point of view as they can see themselves having to redo it later on anyway. In the open source world, the driving theme is that there is often something good enough to not require reinventing the wheel but, in the end, "if you want a job done right, you've got to do it yourself." -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Missing: Universal-CD - Gentoo discriminates shell and networkless users
On Tuesday 10 October 2006 03:45, Kari Hazzard wrote: > On Monday 09 October 2006 6:30 pm, Alec Warner wrote: > > I concur with Donnie here; Gentoo exists not because of Users, but > > because of (a subset of active) Developers. It isn't a statement that > > is meant to trash users (because you are quite helpful in many > > instances). But the naive thought that Gentoo revolves around users > > iswell, naive. Gentoo was here before there were thousands of > > users, in the unlikely event that you all switch distros, Gentoo will > > probably still be here. > > It will not, however, have anywhere near as many developers, nor will it > have more than a fraction of the resources now available to it. Users are > the reason people sponsor Gentoo, users are the reason people know Gentoo > exists, whether you realise it or not. You miss the point entirely. Unpaid software authors do it because they want to use the software themselves. Those authors that publish their source generally do so because they see it as an overall waste of time for the proverbial wheel to be reinvented by others. I'd say they also do it because they are happy in the thought that 9 times out of 10 they'll find some other author has published source to achieve a new goal of their own saving them from having to reinvent the wheel themselves. So how does this fit in with sponsors and volumnuous resources? Well, it doesn't. But then, it was never meant to. So called "end users" that don't give back to the project (giving resources is a way of giving back, by the way) make of more than 99% of those that utilize the resources provided by sponsors. Sponsoring is essentially payed advertising that wasn't done with dollars (or yen, etc) and has a generally high risk return. If referring to the "sponsor a dev" program, it's still a similar give-take scenario. It either falls into the above scenario (that is, a lesser funded dev needs highly supported hardware to continue his regular work, gets it and blogs about it) or it falls into the category of poorly supported hardware - or both categories. In the case of the latter category, the dev is likely just looking for the learning experience when taking the hardware and building up support for it. It's all about win-win situations. I don't know what the original post was about. I only read this one because "I concur with Donnie here" caught my eye. But whatever was being asked for in the original post (I'm assuming that this sub-thread started with somebody asking for something?), would the dev get anything back for satisfying the request other than a less stressful time perusing their inbox? > > To make another argument; if I go buy a RHEL3 box set and then complain > > because the liveCD doesn't have some key programs (lets say > > cryptsetup-luks statically compiled so I can boot off of a USB key and > > encrypt my / partition), is the onus on them to release a new CD just > > for me? Hell I'm a paying customer! But they don't care. > > Well, that's simply bad customer service. > > Don't constrict your support organ because someone else's support organ > operates poorly. That doesn't help anyone, not users, not devs. The initial premise for Alec's argument above is just wrong as when you go out and buy a RHEL3 box set you're not actually buying the software contained within. What you're buying is a set of installation CDs and an X month/year support contract. When you purchase Gentoo CDs, you're buying a set of installation CDs only. When you're downloading Gentoo, you're not purchasing anything. I'll try to answer your response to his invalid point, though. Whichever product you buy, the licenses for the software contained therein almost never place any requirements on the licenser, rather only on the licensee. This is true even when it comes to Microsoft, Apple, etc. If you actually go and read most of the commercial licenses, it boils down to "This software is provided AS IS - except that you can't make copies, resell, use on more than one computer or by more than one person, etc." > In any event, when was the decision made to kill the Universal LiveCD for > x86 and replace it with the installer? I'd like to read the discussion. I have a feeling the discussion took place about 18 months ago on -core, but I'm not sure as to the answer to this. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Profile masking and profiles package.mask
On Monday 02 October 2006 16:03, Jason Stubbs wrote: > 1) Specifying >=sys-libs/glibc-2.4 and thus a corresponding entry in package.mask ... is redundant -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Profile masking and profiles package.mask
On Saturday 30 September 2006 04:40, Diego 'Flameeyes' Pettenò wrote: > This is a discussion to follow up bug #149508 [1]. Posted on the bug before noticing there was a -dev thread. """ Just about everybody has the wrong idea here. 1) Specifying =sys-libs/glibc-2.4 and thus a corresponding entry in package.mask 2) What should be done is to specify >=sys-libs/glibc-2.4 and leave masking out altogether for packages The reason that package.mask was added to profiles was so that masking of atoms in packages could be killed off and it could become just a list of required packages. """ Like Marius said, using packages to both define what's required of "system" and for masking packages is bad design. That and the hope of eventually being able to kill off profiles/package.mask are the only reasons package.mask was introduced into profiles. > I cannot find myself any reason for such a behaviour change, but I'm open > to be proven wrong. The original reason for specifying masking in both packages and package.mask was that there were portage versions that didn't look at package.mask. That was a long time ago though, so masking should really be dropped from packages altogether at this late stage. However, masking in packages only is still supported. If there is a reason that the plans for killing off that support should be suspended, that's also viable. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Making the developer community more open
On Tuesday 21 March 2006 12:32, Alec Warner wrote: > m h wrote: > > I'm not a gentoo dev (just a satisfied user), but I lurk on this list. > > > > I was at PyCon last month. I would estimate that about 40% of the > > people there ran linux on their laptops. The most popular distros > > were gentoo and ubuntu. (Not this is not a scientific study, just my > > observations from talking to people there). While I was there the > > person next to me starting hacking the ebuild classes to handles eggs > > (so he could emerge turbogears). I talked to at least 3 others who > > were running gentoo. I asked all of them if they had worked on > > portage. Most said "No, the code is a little scary". (I'll concur > > with that sentiment, as the code doesn't feel very pythonic). > > > > If you want to attract more developers (python people), a few things are > > needed: > > That depends on how they contribute, I personally don't want random > python master bob contributing pieces to portage itself. Portage things > are not necessarily as simple as people make them out to be. Even > developers who know the code well make mistakes in adding and removing > code. As solar once pointed out "the only man I trust to touch the > resolver is Jstubbs." I realize thats a bit elitest...but at the same > time...I am overly cautious ;) The resolver as it stands now is not overly difficult. One does really need to know it back to front though. I should really make splitting it out and documenting it my big project for 2.2. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] USE_EXPAND in IUSE ( again )
On Saturday 11 March 2006 14:19, Alec Warner wrote: > Either USE_EXPAND always goes in IUSE, or USE_EXPAND never goes in IUSE. Regardless of what is displayed, portage will eventually need to know what USE_EXPAND env vars are modifying the behaviour of an ebuild. Consider extending --newuse to support USE_EXPAND as well. Simply knowing the var itself isn't quite enough. Could you imagine if every single package that is modified by USE were recompiled when irrelevant parts of USE is changed? > If you want USE_EXPAND that sometimes goes in IUSE and sometimes doesn't > you better have a good plan for keeping those lists of proper USE_EXPAND > flags and improper flags in sync. I mean I'd love to do it that way, > but I'll bet those lists get old and nasty and we will have people > complaining about QA warnings that they thought were fixed or that there > were no QA warnings when there should have been...etc.. I also committed support for a USE_EXPAND_HIDDEN. Individual flags don't need to be added to it. USE_EXPAND_HIDDEN="USERLAND ARCH ..." is enough. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
On Saturday 04 March 2006 23:45, Danny van Dyk wrote: > Am Samstag, 4. März 2006 14:24 schrieb Thomas de Grenier de Latour: > > One point of view on this issues is that the ebuilds are wrong, because > > they are abusing the said USE flags, and they should rather die. Imho, > > it makes sense, but if such a strict policy was applied to every > > ebuilds which atm are abusing flags this way, it would become really > > hard to put anything in the make.conf USE variable without breaking > > "emerge -uD world". > > Just to throw in my 2 cents into this discussion: I'm all against die-ing > during the update process. However, i think that stopping before the update > process would be the best solution at hand. I'd like to propose the addition > of a dedicated USE conflict detection to ebuilds which need it. This sounds the most reasonable. I can't see portage ever supporting "the 'foo' and 'bar' flags can be used together except when 'baz' is also used" type flag interdepency complexity. As Mike pointed out, check_license also needs to be accounted for as well as possible others. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] "emerge -NDuvp world" takes forever after "emerge sync"
On Saturday 25 February 2006 18:39, Sebastian Bergmann wrote: > For a while I am experiencing the following portage annoyance: > > After an "emerge sync" (for which the metadata/cache update takes about > ten seconds), the first call to "emerge -NDuvp world" takes between > five and ten minutes > >emerge -NDuvp world 321.05s user 77.90s system 94% cpu 7:02.77 total > > I am using sys-apps/portage-2.1_pre4-r1. Open a bug for this please. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Passing the buck
On Thursday 09 February 2006 20:23, Jason Stubbs wrote: ... Wrong list :/ -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Passing the buck
On Thursday 09 February 2006 15:00, Brian Harring wrote: > On Sun, Feb 05, 2006 at 03:04:08PM +0900, Jason Stubbs wrote: > > Hi all, > > > > Time again for one of those mails; this time from me. Due to time > > constraints, > > real life and coming close to burning out I'm stepping down as release > > coordinator. Brian has graciously accepted shouldering the burden until he > > starts to burn out or some insane bugger comes along and wrestles him for a > > slice of the action. > > And I suck, because I'm going to pass the buck now. > > The .5x release, and 2.1.pre5 realease I'll handle; if 2.1 proves > stable, and doesn't take forever I'll see it through, but I'm taking > at least a hiatus from gentoo. I'll pull it back if you like, but it means I'll pretty much not have time for anything else. While I've been fed up with the bullshit myself in the past, the feeling is somewhat subdued at the moment so I can get right back into it if you like. Not that I stopped reading through the commits anyway; habits are hard to break. ;) I'll have a little more time than I estimated for the time being anyway. Dell wants us to pay $35K for the hardware and then $50K+ on top of that for them to configure and install the redhat on it all. :/ (== SAN has been postponed) Long term, same deal though. Perhaps it would be a good idea to get those interested in it together and can try to get some documentation together. That should at least make the executor less important... -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Binary packages
On Thursday 09 February 2006 09:30, Mark Loeser wrote: > Jason Stubbs <[EMAIL PROTECTED]> said: > > It was my understanding that it is needed for the 3.3 -> 3.4 upgrade. > > Various packages that will build fine against either are broken until > > being recompiled after the upgrade and there is currently no way to > > express this with dependencies. > > You need either gcc-3.3 or libstdc++-v3. I don't see forcing either upon our > users to be a good thing. The upgrade doc covers how to do the 3.3->3.4 > upgrade, and I think most archs are on 3.4 at this point. Ok. If the there's an upgrade doc and 3.4 postinst points to it, no problem. I take it the dependencies you're asking about is for binary-only (or other?) packages that specifically depend on 3.3 then? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Binary packages
On Thursday 09 February 2006 08:19, Mark Loeser wrote: > Anyone that is maintaining a binary package in the tree, and requires > libstdc++-v3, please put a rdepend in your package on > =virtual/libstdc++-3.3. I'd like to drop the dependency from gcc-3.4 and > higher so that we do not needlessly force the libstdc++ package on people > that do not need it. It was my understanding that it is needed for the 3.3 -> 3.4 upgrade. Various packages that will build fine against either are broken until being recompiled after the upgrade and there is currently no way to express this with dependencies. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] IUSE and LINGUAS?
On Tuesday 31 January 2006 22:39, Mike Frysinger wrote: > On Tuesday 31 January 2006 06:31, Jason Stubbs wrote: > > On Monday 30 January 2006 20:54, Ciaran McCreesh wrote: > > > 1. Because for things like LINGUAS, there are arbitrarily many legal > > > values, and documenting them all and keeping the list up to date would > > > be extremely difficult. > > > > "More precisely, how should they be documented if not via use.desc?" > > considering there's a ton more LINGUAS values than we have USE flags (just > run > `wc` on use.desc and lang.desc), bloating use.desc with LINGUAS settings > benefits *noone* > > we have lang.desc, it is quite populated, what's wrong with having portage > read that Absolutely nothing. I am in no way suggesting that use.desc is the possible fix. I wasn't even suggesting that each individual flag need be documented. However, if lang.desc already exists (and it does) and can be renamed to linguas.desc, it is probably a better way to manage it than use.desc. Is having INPUT_DEVICES and the like following the same scheme (ie, input_devices.desc) acceptable? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Unmasking modular X
On Wednesday 01 February 2006 02:28, Mark Loeser wrote: > Jason Stubbs <[EMAIL PROTECTED]> said: > > Is there any need for the packages to go into stable without the X deps > > being > > fixed? Why not just open a bug for the package maintainer and mark it > > against > > whatever bug is requesting stabling of that package? Moving something to > > stable that you know is going to be broken within a relatively short > > timeframe seems like a very bad idea... > > We are talking about completely unrelated versions, not what we are touching. > For example, old imagemagick ebuilds sitting around, where the newer ebuilds > are fixed, but old ones are not. We have a security bug open about this > package right now, and having an error about deps in some old version doesn't > really help arch teams at all. Security bugs are about the only time I can see any urgency. That's not a good reason to completely degrade the error though. A switch similar to --ignore-other-archs that skips certain checks for urgent fixes seems reasonable though. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] IUSE and LINGUAS?
On Monday 30 January 2006 20:54, Ciaran McCreesh wrote: > On Mon, 30 Jan 2006 20:46:28 +0900 Jason Stubbs <[EMAIL PROTECTED]> > wrote: > | On Monday 30 January 2006 16:43, Ciaran McCreesh wrote: > | > On Mon, 30 Jan 2006 06:17:36 +0100 "Diego 'Flameeyes' Pettenò" > | > <[EMAIL PROTECTED]> wrote: > | > | Also, as repoman complain about linguas_blabla not being a valid > | > | useflags, all the linguas_* useflags should be listed in use.desc > | > > | > No, part of the point of USE_EXPAND is that they shouldn't. This is > | > a repoman bug. > | > | I have yet to be enlightened on any merit of USE_EXPAND is so perhaps > | you could explain as to why there should be > | user-configured-yet-undocumented options for ebuilds? More precisely, > | how should they be documented if not via use.desc? > > 1. Because for things like LINGUAS, there are arbitrarily many legal > values, and documenting them all and keeping the list up to date would > be extremely difficult. "More precisely, how should they be documented if not via use.desc?" > 2. Because USE_EXPAND is used for special USE things like arch and > userland, and because we undocumented the special arch USE flags > because they're not user settable. These variables are internal and not meant to be user configurable. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Unmasking modular X
On Tuesday 31 January 2006 13:49, Joshua Jackson wrote: > Mark Loeser gentoo.org> writes: > > Donnie Berkholz gentoo.org> said: > > > Jason Stubbs wrote: > > > > The patch now has the debugging output and x11-base/xorg-x11 check > > > > removed. > > > > > > Excellent. Works perfectly. Since we're failing on them, perhaps we can > > > say "obsolete" instead of "deprecated"? > > > > Can we put this back to being a warning? It makes things a pain for arch > > teams that are trying to mark a completely unrelated version of the > > package. > > I will have to agree that this change has made it a pain to mark anything > stable. I had 4 out of the 6 I did today bail out because of this. I took > the simple easy fix and removed the check to stabalize the packages I needed > to. I know we have people who want modular X yesterday, but causing trouble > for dev's going about business that doesn't involve the modular problems > directly is only going to cause resentment and frustration to all the teams > involved. Is there any need for the packages to go into stable without the X deps being fixed? Why not just open a bug for the package maintainer and mark it against whatever bug is requesting stabling of that package? Moving something to stable that you know is going to be broken within a relatively short timeframe seems like a very bad idea... -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] IUSE and LINGUAS?
On Monday 30 January 2006 16:43, Ciaran McCreesh wrote: > On Mon, 30 Jan 2006 06:17:36 +0100 "Diego 'Flameeyes' Pettenò" > <[EMAIL PROTECTED]> wrote: > | Also, as repoman complain about linguas_blabla not being a valid > | useflags, all the linguas_* useflags should be listed in use.desc > > No, part of the point of USE_EXPAND is that they shouldn't. This is a > repoman bug. I have yet to be enlightened on any merit of USE_EXPAND is so perhaps you could explain as to why there should be user-configured-yet-undocumented options for ebuilds? More precisely, how should they be documented if not via use.desc? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] IUSE and LINGUAS?
On Monday 30 January 2006 14:17, Diego 'Flameeyes' Pettenò wrote: > [ebuild R ] media-tv/kdetv-0.8.8-r1 USE="-arts -debug -lirc -opengl > -xinerama -zvbi" LINGUAS="it% -bg% -br% -ca% -cs% -cy% -da% -de% -el% > -en_GB% -es% -et% -fi% -fr% -ga% -gl% -hu% -is% -lt% -mt% -nb% -nl% -pa% > -pl% -pt% -pt_BR% -ro% -ru% -rw% -sr% [EMAIL PROTECTED] -sv% -ta% -tr% > -zh_CN%" 0 kB This would only be on the first installation. The "%" symbol indicates that the flags have been added. On the second run it would become: > [ebuild R ] media-tv/kdetv-0.8.8-r1 USE="-arts -debug -lirc -opengl > -xinerama -zvbi" LINGUAS="it -bg -br -ca -cs -cy -da -de -el -en_GB -es -et > -fi -fr -ga -gl -hu -is -lt -mt -nb -nl -pa -pl -pt -pt_BR -ro -ru -rw -sr > [EMAIL PROTECTED] -sv -ta -tr -zh_CN" 0 kB Not a huge difference but not exactly minor either. And of course LINGUAS="" wouldn't be shown at all if nothing had changed with regard to it and --verbose wasn't specified. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Unmasking modular X
On Thursday 26 January 2006 22:09, Jason Stubbs wrote: > There is no way that I can see around this without highly increasing the > possibility of false positives. I extracted a list of cps from repoman, modified your script to check all cpvs (rather than only the best) and compared that with repoman's cps. The attached result.diff file prefixes repoman-only detection with a "-" and the separate tool-only detection with a "+". Your fixes to seem to producee many false positives and introduce some false negatives as well. There may be true positives that I'm missing but I couldn't find one picking a few cases at random. Either way, it doesn't matter if there a few false negatives as it's only meant to be an aid. False positives on the other hand are unacceptable. -- Jason Stubbs +app-accessibility/gok -app-cdr/nero +app-editors/nvu +app-editors/vim +app-editors/zoinks -app-emulation/cedega +app-emulation/dosemu -app-emulation/pearpc -app-emulation/point2play +app-emulation/vice -app-emulation/vmware-workstation +app-emulation/wine -app-emulation/winex-transgaming +app-i18n/kinput2 -app-i18n/uim-svn +app-misc/beagle +app-misc/oneko -app-misc/tkpasman -app-office/mozilla-sunbird-bin +app-office/magicpoint +app-office/openoffice +app-office/openoffice-ximian -app-pda/qtopia-desktop-bin -app-portage/portagemaster +app-portage/test +app-shells/fish +app-text/cstetex +app-text/gv +app-text/ptex -dev-embedded/ponyprog +dev-games/ode -dev-java/gnu-classpath +dev-java/blackdown-jre -dev-lang/smalltalkx +dev-lang/swi-prolog-lite -dev-lisp/mit-scheme +dev-util/insight -dev-util/weka -games-action/phobiaiii +games-action/tuxkart +games-action/xpilot +games-action/xpilot-ng -games-arcade/emergence-bin +games-arcade/koules -games-arcade/mtp-target-bin +games-arcade/ppracer +games-arcade/xgalaga +games-arcade/xjump +games-board/cgoban -games-emulation/boycott-advance-sdl -games-emulation/dgen-sdl -games-emulation/hugo -games-emulation/kigb -games-emulation/mastergear-bin +games-emulation/snes9x -games-emulation/vgba -games-fps/fuhquake-bin -games-fps/postal2mpdemo -games-fps/unreal -games-fps/vendetta-online-bin -games-puzzle/pauker -games-puzzle/triptych-demo +games-puzzle/xwelltris +games-roguelike/nethack -games-server/WarpPipe +games-server/crossfire-server +games-sports/miniracer +games-sports/ultimatestunts +games-strategy/freeciv +gnome-base/control-center +gnome-base/nautilus -mail-client/ciphire-mail -mail-client/mozilla-thunderbird-bin +kde-base/kdesktop +mail-client/mozilla-thunderbird +media-fonts/x11fonts-jmk +media-gfx/fbida -media-gfx/povtree -media-libs/devil +media-libs/gd +media-libs/giblib +media-libs/glide-v3 -media-libs/hamlib +media-libs/libcaca +media-libs/libmpeg2 +media-libs/libquicktime +media-libs/plib +media-libs/urt -media-libs/xpm +media-plugins/libvisual-plugins -media-radio/tucnak1 -media-radio/xconvers -media-radio/xdx -media-radio/xlog -media-sound/mup +media-tv/kdetv +media-tv/xdtv +media-video/motioneye +media-video/mplayer +media-video/xanim -media-video/yanc +net-analyzer/sara -net-im/ymessenger +net-libs/gecko-sdk -net-misc/ltsp -net-misc/mindterm -net-misc/nxserver-business -net-misc/nxserver-enterprise -net-misc/nxserver-personal +net-misc/vnc -net-misc/xsmbrowser -net-nntp/bnr2 -net-p2p/phex +net-print/xpp +net-www/gnash +net-www/mplayerplug-in +sci-chemistry/ghemical +sci-chemistry/gopenmol -sci-chemistry/nmrpipe -sci-chemistry/nmrview +sci-chemistry/rasmol +sci-chemistry/viewmol +sci-electronics/spice +sci-libs/libgdgeda +sci-misc/boinc +sys-apps/pcmcia-cs +sys-devel/gcc +www-client/elinks -www-client/mozilla-bin -www-client/mozilla-firefox-bin +www-client/mozilla +www-client/mozilla-firefox -www-client/opera +x11-libs/Xaw3d +x11-libs/libdockapp +x11-libs/libxsettings-client +x11-libs/qt +x11-libs/startup-notification +x11-misc/3ddesktop +x11-misc/accessx +x11-misc/autocutsel -x11-misc/commonbox-utils +x11-misc/chgres +x11-misc/dclock +x11-misc/electricsheep +x11-misc/fireflies +x11-misc/fspanel +x11-misc/fxred +x11-misc/hsetroot +x11-misc/imwheel +x11-misc/mixer_app +x11-misc/numlockx +x11-misc/obpager +x11-misc/pogo +x11-misc/seyon +x11-misc/skippy +x11-misc/temperature-app +x11-misc/transset +x11-misc/vnc2swf +x11-misc/wayv +x11-misc/x2vnc +x11-misc/x2x +x11-misc/xautomation +x11-misc/xbatt +x11-misc/xbattbar +x11-misc/xcalendar +x11-misc/xcb +x11-misc/xclip +x11-misc/xcompmgr +x11-misc/xcut +x11-misc/xdaf +x11-misc/xdaliclock +x11-misc/xearth +x11-misc/xfishtank +x11-misc/xfm +x11-misc/xhkeys +x11-misc/xinput +x11-misc/xkbd +x11-misc/xkeycaps +x11-misc/xmountains +x11-misc/xnc +x11-misc/xnview +x11-misc/xplanet +x11-misc/xrestop +x11-misc/xrmap +x11-misc/xsetleds +x11-misc/xsimpsons +x11-misc/xsnap +x11-misc/xsnow +x11-misc/xstroke +x11-misc/xteddy +x11-misc/xtoolwait +x11-misc/xtrlock +x11-misc/xvidcap +x11-misc/xvkbd +x11-misc/xwit +x11-misc/xwrits +x11-misc/xxkb +x11-plugins/allin1 +x11-plugins/cputnik +x11-pl
Re: [gentoo-dev] Unmasking modular X
On Thursday 26 January 2006 20:56, Brian Harring wrote: > Patch misses on > || ( virtual/x11 ) A theoretical case, but if you want to cover it... > || ( x86? ( virtual/x11 ) b ) > via the latter, kind of guranteed it's going to miss on It's not a "miss" per se as much as other dependency checks that aren't performed are a miss when there is invalid syntax - which prevents a commit anyway. If you make "b" a proper atom that specifies a category it'll be picked up. > || ( x86? ( valid-dep ) virtual/x11 ) There is no way that I can see around this without highly increasing the possibility of false positives. Are you planning to treat arch flags separately? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Unmasking modular X
On Thursday 26 January 2006 16:08, Donnie Berkholz wrote: > It prints about 10X of crap like this: > > virtual/libc !virtual/xemacs berkdb? ( =sys-libs/db-1* > >=sys-libs/gdbm-1.8.0 ) >=sys-libs/zlib-1.1.4 >=dev-libs/openssl-0.9.6 > >=media-libs/audiofile-0.2.3 gpm? ( >=sys-libs/gpm-1.19.6 ) postgres? ( > >=dev-db/postgresql-7.2 ) ldap? ( net-nds/openldap ) nas? ( > media-libs/nas ) dnd? ( x11-libs/dnd ) X? ( virtual/x11 ) motif? ( > >=x11-libs/openmotif-2.1.30 ) athena? ( virtual/x11 ) Xaw3d? ( > x11-libs/Xaw3d ) neXt? ( x11-libs/neXtaw ) xface? ( media-libs/compface > ) tiff? ( media-libs/tiff ) png? ( =media-libs/libpng-1.2* ) jpeg? ( > media-libs/jpeg ) canna? ( app-i18n/canna ) !amd64? ( freewnn? ( > app-i18n/freewnn ) ) >=sys-libs/ncurses-5.2 !bootstrap? ( sys-devel/patch ) This was testing/debugging left in by mistake. > Then doesn't print the one line saying > "app-editors/xemacs/xemacs-21.4.15-r3.ebuild: RDEPEND has deprecated x11 > dependencies" without a "full" listing? That doesn't make sense -- if it > has to be one way or the other, it should be the reverse. That's a standard repoman thing. Details are only printed if there are less than 12 occurrences of a specific warning unless "repoman full" is run. Not sure why it wasn't being displayed if there was only one occurrence. The patch now has the debugging output and x11-base/xorg-x11 check removed. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Unmasking modular X
On Wednesday 25 January 2006 21:47, Brian Harring wrote: > On Wed, Jan 25, 2006 at 09:18:28PM +0900, Jason Stubbs wrote: > > 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. This is off-topic now. > > 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) ;) Would 10 days or 17 days really be any different? > > 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. Such as warning/failing on: * the server's repository path is "/space/cvsroot" * any extensions to metadata.xml * larger-than-20k-files * not being copyrighted to Gentoo Foundation * not being distributed under GPLv2 There's probably others but all of those things are Gentoo specific and cause no less trouble than what a virtual/x11 check might cause. > So... long term? Refactor/rewrite/modularize/blah repoman. In the mean time, make do with what we have and let Gentoo derivatives do the same. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Unmasking modular X
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 ;) Get off it. There's no other way to do it given repoman's state and the requirements. 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 Besides, what's wrong with hardcoded atoms in repoman anyway? Repoman doesn't have to stand the test of time. Conversely, it should represent checks for whatever issues are present in the tree at the time of its release. http://dev.gentoo.org/~jstubbs/x11_deprecation_check.diff -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Unmasking modular X
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? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Unmasking modular X
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). -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Unmasking modular X
On Wednesday 25 January 2006 16:40, Donnie Berkholz wrote: > Ciaran McCreesh wrote: > > On Wed, 25 Jan 2006 16:08:07 +0900 Jason Stubbs <[EMAIL PROTECTED]> > > wrote: > > | The premise for not doing this is that packages will never be fixed, > > | right? Why not make the modular X provide virtual/x11 and just > > | institute a policy that no new packages can go into stable with a > > | virtual/x11 dependency? It could even be easily enforcable if > > | necessary. > > > > Much more sensible. > > I've thought some about this. It would be acceptable to me for > virtual/x11 to provide modular X deps, if we also instituted a repoman > death upon any attempt to commit to a directory for which the best > visible package is broken. > > This will accomplish the goal of discovering completely unmaintained > packages but will fail in the goal of discovering which packages nobody > uses. They'll still continue to rot in the tree, unmaintained, unused > and taking up space in everybody's syncs. > > How's that sound? 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. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Unmasking modular X
On Wednesday 25 January 2006 16:19, Donnie Berkholz wrote: > Jason Stubbs wrote: > > Only by modifying every ebuild that has a virtual/x11 dependency. The atom > > "virtual/x11" cannot be limited to specific versions on its own with old > > style virtuals. > > Is that so? I guess this must be wrong, then: > > /usr/portage/profiles/base/virtuals:# Only have this for >=pam-0.78, as > we want to make use of the 'include' > /usr/portage/profiles/base/virtuals:virtual/pam > >=sys-libs/pam-0.78 Yep, portage simply removes the >= and 0.78 parts and makes all versions of sys-libs/pam a provider of virtual/pam. Why there is no warning I don't know. > > The premise for not doing this is that packages will never be fixed, > > right? Why not make the modular X provide virtual/x11 and just institute a > > policy that no new packages can go into stable with a virtual/x11 > > dependency? It could even be easily enforcable if necessary. > > How does that fix the stale, unmaintained here and upstream apps that > are in stable now and have no ~arch ebuilds? It wouldn't, but at least there'd be fewer packages to deal with in the final cleanup. It was just an innocent question though; as far as I can tell, emerging any application (ported or not) on a clean system will not break even after modular X is unmasked. It's a fine line between whether packages "needlessly" not working together due to incompatible (deep) dependencies is considered breakage or not though... /me steps away from the flames for fear of getting burned. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Unmasking modular X
On Wednesday 25 January 2006 15:53, Ciaran McCreesh wrote: > On Tue, 24 Jan 2006 22:28:09 -0800 Donnie Berkholz > <[EMAIL PROTECTED]> wrote: > | > * The clean solution is the solution originally proposed to this > | > list, and the reason we are using new style virtuals. > | > | No, this is wrong. The reason we are using new style virtuals is so we > | could have a versioning in what provides virtual/x11. Namely, 6.8 or > | older. > > Uh, given that you can do that with old style virtuals, methinks that > isn't the case... Only by modifying every ebuild that has a virtual/x11 dependency. The atom "virtual/x11" cannot be limited to specific versions on its own with old style virtuals. > | > * You are doing this because you believe that it is better to get > | > every package ported over extremely quickly rather than having the > | > odd package with extra unnecessary listed dependencies, and you do > | > not consider the impact upon our users to be relevant. > | > | I consider ~arch users to have agreed to help test and fix new things. > | This is included. I would not do the same thing to our stable tree, or > | if we only had a stable tree. > | > | Yes, I do think it is better to have a quick solution and let some of > | our ~arch users see a couple of blocks, for which they will file bugs. > | Then these bugs will be fixed within a day, and those users will again > | have working systems. > > ...or you could do things as originally planned, and have no > non-working systems at all and the only consequences for end users will > be a small number of extra packages (that they previously had installed > anyway as part of hugeass X) being pulled in. The premise for not doing this is that packages will never be fixed, right? Why not make the modular X provide virtual/x11 and just institute a policy that no new packages can go into stable with a virtual/x11 dependency? It could even be easily enforcable if necessary. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] [POLL] portage-2.1 USE flag ordering
Hi all, I've started a poll on the specific question of USE flag ordering in portage-2.1_pre3 at http://forums.gentoo.org/viewtopic-t-426033.html The result of the poll will pretty much dictate what will happen in the next release so if you'd like to go over and cast your vote... :) There's also a more general poll at http://forums.gentoo.org/viewtopic-t-423275.html which also allows further discussion if anybody is wanting to offer detailed opinions. Thanks in advance. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] SuperH (sh) KEYWORD spam
On Saturday 31 December 2005 18:57, Mike Frysinger wrote: > i'm injecting sh KEYWORDS as quickly as my lantank can emerge ... So that's one package every two weeks then? ;) -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
On Friday 30 December 2005 22:13, Spider (DmD Lj) wrote: > it would block against "requirement of same package with different SLOT. > > However, since the ~ atoms are explicit and separate ( this depend tree > could as well be called : > app-text/docbook-sgml-dtd:3.0 > app-text/docbook-sgml-dtd:3.1 > app-text/docbook-sgml-dtd:4.0 > app-text/docbook-sgml-dtd:4.1 > > Which, for some reason, should be supported : ) > > Either by casing out appearances where multiple SLOTs are depended on by > -one- package, or by saying that ~ is special-cased due to its stricter > limitations, which would make it pass by the SLOT check. > > ( no, its not an elegant solution, but it might work ;) Inelegant solutions gets us no further than where we are now. ;) A still inelegant solution, but one that I could live with, is to leave SLOT handling as it is now and to take Brian's syntax of key:slot,slot using it specifically for the case where a set of ebuilds must all use the same slot. Hence, rather than digikam and friends having "|| ( kdelibs:3.4 kdelibs:3.5 )" each would have just "kdelibs:3.4,3.5". It still sounds messy given the current redesign of atom handling, but it would seem to offer a better chance of not being bug-ridden... -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
On Friday 30 December 2005 21:17, Spider (DmD Lj) wrote: > On Fri, 2005-12-30 at 10:35 +0900, Jason Stubbs wrote: > > On Friday 30 December 2005 01:35, Spider (DmD Lj) wrote: > > > On Tue, 2005-12-27 at 19:06 +, Ciaran McCreesh wrote: > > > > On Tue, 27 Dec 2005 19:53:14 +0100 Carsten Lohrke <[EMAIL PROTECTED]> > > > > > > Thats actually viable. For -installed- ebuilds, we simply unpack all > > > RDEPEND logic, remove all use flags ( stored, but the use logic is > > > removed from the RDEPEND since its already resolved, doesn't need to be > > > there. The binary is static already ) > > > > > > Then check vs. the installed SLOT of all RDEPEND packages, and lock our > > > current deptree to the package of that SLOT... > > > > I suggested this last Tuesday.. > > No, what you suggested was that for the case of when you depend on a > SLOT, then the tree is flattened. My point was for the generic case : > > DEPEND=">=kde-base/kdelibs-3.0" (as many ebuilds look today) > > is then expanded to the current matching SLOT of kdelibs, so even if > there -wasn't- a SLOT requirement beforehand, there is one afterwards. Okay, I misinterpreted. Anyway, it looks like neither of our ideas will work: app-text/docbook-sgml/docbook-sgml-1.0.ebuild: RDEPEND="app-text/sgml-common app-text/openjade >=app-text/docbook-dsssl-stylesheets-1.64 >=app-text/docbook-sgml-utils-0.6.6 ~app-text/docbook-sgml-dtd-3.0 ~app-text/docbook-sgml-dtd-3.1 ~app-text/docbook-sgml-dtd-4.0 ~app-text/docbook-sgml-dtd-4.1" docbook-sgml-dtd-3.0-r3.ebuild:SLOT="3.0" docbook-sgml-dtd-3.1-r3.ebuild:SLOT="3.1" docbook-sgml-dtd-4.0-r3.ebuild:SLOT="4.0" docbook-sgml-dtd-4.1-r3.ebuild:SLOT="4.1" -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
On Friday 30 December 2005 01:35, Spider (DmD Lj) wrote: > On Tue, 2005-12-27 at 19:06 +, Ciaran McCreesh wrote: > > On Tue, 27 Dec 2005 19:53:14 +0100 Carsten Lohrke <[EMAIL PROTECTED]> > > > > wrote: > > | On Tuesday 27 December 2005 18:59, Ciaran McCreesh wrote: > > | > Nnnope. If you modify an eclass it forces a cache regen for packages > > | > using said eclass (except possibly if you're using an overlay, but > > | > that's a separate issue...). > > | > > | You're trying to solve something which is already solved, but this > > | has nothing to do with our problem. The question is not listen the > > | possible valid KDE versions or a change of the eclass, but the need > > | to know actual used KDE version. You'd need to call e.g. kde-config > > | to get it. And this breaks caching. > > > > So you RDEPEND upon the version of KDE against which you were built, > > and use the || ( ) flattening feature that's already been proposed. > > Thats actually viable. For -installed- ebuilds, we simply unpack all > RDEPEND logic, remove all use flags ( stored, but the use logic is > removed from the RDEPEND since its already resolved, doesn't need to be > there. The binary is static already ) > > Then check vs. the installed SLOT of all RDEPEND packages, and lock our > current deptree to the package of that SLOT... I suggested this last Tuesday.. > I can smell sooo much breakage from this solution. Even though it could > work : ) I'm not sure to interpret this as "yet another snide remark" or not so I'll give you the benefit of the doubt and assume you're referring to sets of ebuilds that require several slots. Before implementing the above, the tree will be checked for any cases where the above idea will fail. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
> On Monday 26 December 2005 21:28, Ciaran McCreesh wrote: > > On Mon, 26 Dec 2005 21:09:31 +0100 Carsten Lohrke <[EMAIL PROTECTED]> > > Well, any library that changes ABI should use a different SLOT for each > > revision. So SLOT depends should be able to replace the need for = and > > ~ and < and <= dependencies entirely. Which is a good thing, since > > those atoms make dependency resolution a general-case unsolvable > > problem. There's a lot of "should"s that are "aren't"s in there, but in principle that is a very elegant idea. On Wednesday 28 December 2005 00:48, Paul de Vrieze wrote: > Well, it shouldn't be unsolvable. Choosing can be done with the following > process: > > - Get the list of packages with the requested name. > - Sort the list from the newest version, to the oldest. > - Iterate over the packages: > - Apply all restrictions on the package (including exclusions). If the > package satisfies all, test it's dependencies recursively. ^^^ This step fails. When the set of restrictions cannot be resolved, you need to backtrack and try a lesser version of a previous package hence the set of "all restrictions" is constantly in flux. > - If all dependencies match, this package matches the dependency. > Continue with the next depend atom. > - If no match, iterate the next package. If backtracking was all there was to it, it could be done very quickly of course. However, it's essentially a brute force method; I'm not very good with O notation but I think it's O(n^n). I've got an algorithm in my head that'll do it but it goes into an infinite loop in the cases that Carsten mentioned. That's why things are taking so long. I should really write it down... -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
On Tuesday 27 December 2005 22:45, Carsten Lohrke wrote: > On Tuesday 27 December 2005 14:00, Jason Stubbs wrote: > > If all three of those packages were first built against kdelibs:3.4 and > > then kdelibs:3.5 became available then rebuilding any one of them without > > rebuilding the others will break digikam. I can't see how it's directly > > represented in the metadata unless you want to overload the meaning of > > SLOT. > > It's not possible to represent that via dependencies. What is needed is > some sort of introspection which relevant ebuild is built against which KDE > version and if those _installed_ ebuild:kdever combinations match the one > the _actual_ ebuild to emerge. Do you mind reading and replying to the second paragraph (which happens to be the only new information I brought to this thread). Underlining words to emphasize a point to me that I've opened by agreeing is really not necessary. > But you're right about the overloading of the meaning of slots, because > that's happening right now. Slots are used to install several versions of a > package side by side. The idea Ciaranm and Brian are proposing to lock > ebuilds depending on slotted packages down to a single slot is the > redefinition. And once again: This doesn't match reality. You've misunderstand what is meant by "locking ebuild dependencies". I gave you a definition in my second paragraph. Please have a re-read. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
On Tuesday 27 December 2005 12:08, Brian Harring wrote: > 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). I may be missing something, but I can't see how this will resolve Carsten's issue. From what I can tell, the ebuilds would be laid out something like: digikam:DEPEND="|| ( kdelibs:3.5 kdelibs:3.4 ) libkipi libkexif" libkipi:DEPEND="|| ( kdelibs:3.5 kdelibs:3.4 )" libkexif:DEPEND="|| ( kdelibs:3.5 kdelibs:3.4 )" If all three of those packages were first built against kdelibs:3.4 and then kdelibs:3.5 became available then rebuilding any one of them without rebuilding the others will break digikam. I can't see how it's directly represented in the metadata unless you want to overload the meaning of SLOT. If overloading, dependencies would be flattened (meaning "|| ( kdelibs:3.5 kdelibs:3.4 )" would have became "kdelibs:3.4" for the original install) within the installed package database but there's also there's the implication that only one slot of a package be allowed in a connected set of nodes. Is that what you're getting at? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on
On Monday 26 December 2005 20:01, Jakub Moc wrote: > >> Currently there are quite a few ebuilds in the tree that execute dodoc > >> or dohtml for files that do not exist. I think it would be nice to have > >> ebuilds die if this is the case. To not break current ebuilds this would > >> only happen with FEATURES="stricter". > > Sigh... There are already bugs flowing in for TEXTRELs/executable stacks > checks implemented in recent portage versions. Some of these bugs are > completely INVALID or CANTFIX - emulation stuff, binary-only ebuilds, etc. > etc. Sigh... None of these issues have made there way to dev-portage. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on
On Monday 26 December 2005 08:14, Brian Harring wrote:
> On Mon, Dec 26, 2005 at 12:54:04AM +0200, Petteri Räty wrote:
> > Currently there are quite a few ebuilds in the tree that execute dodoc
> > or dohtml for files that do not exist. I think it would be nice to have
> > ebuilds die if this is the case. To not break current ebuilds this would
> > only happen with FEATURES="stricter". This is what I currently do in my
> > bashrc. Obviously when integreted to portage one can use helper
> > functions like hasq which are not available in bashrc.
> >
> >
> > if [[ "${FEATURES/stricter}" != "${FEATURES}" ]]; then
> >
> > _makefail() {
> > bin="/usr/lib/portage/bin/${1}"
> > shift 1
> > "${bin}" "[EMAIL PROTECTED]" || die "${bin} [EMAIL PROTECTED] failed"
> > }
> >
> > dodoc() { _makefail ${FUNCNAME} "[EMAIL PROTECTED]"; }
> > dohtml() { _makefail ${FUNCNAME} "[EMAIL PROTECTED]"; }
>
> Seems like more of a -dev discussion imo, since they're the ones
> affected by it (for us it's just an api change).
As a side note, dodoc didn't return non-zero when specified files don't exist
up until a month or two ago. dohtml was updated yesterday. Hence, up until
now the above was not possible.
--
Jason Stubbs
--
gentoo-dev@gentoo.org mailing list
Re: how to contribute to use/slot deps: was Re: [gentoo-dev] Multiple Repo Support
On Sunday 25 December 2005 02:33, 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? Neither. At least for myself, portage development is done to prioritized according to what I see as the needs of users. Needs of "those of us who provide the tree" are prioritized by how much benefit will be translated to end users combined with how much work will be required. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
On Saturday 24 December 2005 12:58, Ciaran McCreesh wrote: > On Sat, 24 Dec 2005 12:50:33 +0900 Jason Stubbs <[EMAIL PROTECTED]> > > wrote: > | SLOT is currently an arbitrary string (without spaces) so general > | matching of "*" might be useful. Of course, there's no restriction of > | not using "*" in SLOTs at the moment either... > > *shrug* SLOT will have to be tightened up anyway. Otherwise > SLOT="[foo]" will cause terrible confusion. Heh. Yep, that's another one. Checking with a quick script, it seems that there are 478 unique SLOTs and the regex [a-zA-Z0-9\._\-]* matches them all. Perhaps it would be worthwhile locking it down to those characters in repoman in preparation? Anybody see a need for characters beyond those? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
On Saturday 24 December 2005 10:25, Ciaran McCreesh wrote: > On Fri, 23 Dec 2005 17:04:32 -0800 Brian Harring <[EMAIL PROTECTED]> > > wrote: > | kde-libs/kde:3 > | ^^^ need any kde, with slotting enabled. > | > | kde-libs/kde:3,4 > | ^^^ need any kde, slotting 3 or 4. I'd prefer to not have this last one. It can be done as "|| ( kde-libs/kde:3 kde-libs/kde:4 )" whereas all other atom constructs are already at their most minimalistic form. > Will foo-bar/baz:3* or foo-bar/baz:3.* work? SLOT is currently an arbitrary string (without spaces) so general matching of "*" might be useful. Of course, there's no restriction of not using "*" in SLOTs at the moment either... -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
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. > 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? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] pkg_{pre,post}inst misusage
On Saturday 24 December 2005 03:42, Thomas de Grenier de Latour wrote: > On Sat, 24 Dec 2005 02:22:06 +0900 > > Jason Stubbs <[EMAIL PROTECTED]> wrote: > > PackageA is installed, PackageB is installed, PackageB is > > uninstalled -> PackageA is broken. Does this case exist? > > Found two on my system: > > * "/usr/lib/X11/app-defaults -> /etc/X11/app-defaults" is > installed by several X11 apps (media-gfx/xfig, x11-misc/seyon, > x11-misc/xvkbd, and i would not be surprised there are others) This looks like something that a lower level X ebuild should be installing. The problem here is that there's also a bit of funny business going on when portage encounters a merge of some filetype being blocked by a different filetype. In the above case, if some X11 package installs the /usr/lib/X11/app-defaults symlink and all other apps install to /etc/X11/app-defaults then everything should be fine. > * "/usr/share/cups/model/foomatic-ppds -> /usr/share/ppd" is > installed by both net-print/foomatic-db and net-print/hplip. Again, given the name of the symlink, net-print/hplip should probably be installing directly to /usr/share/ppd. > Maybe this particular packages could be hacked to avoid need for > the symlinks (or the symlinks should be installed only by some > lower level, depended-on, packages?), but anyway it would be hard > to do a strict sanity check of the whole tree. And letting that to > "collision-protect" feature doesn't sound really like a short term > solution neither. So, basically, i don't see how you could safely > change this portage behavior atm (although i agree it would be a > good thing once done). Yep, it seems that changing the behaviour will lead to some breakage. However repoman is definately not capable of handling this sort of stuff. Also, none of the breakage (that you've revealed here at least) is that bad. Putting the relevant collision-protect changes into ~arch and following up with the actual unmerge changes should lead to minimal disruption on the user's side. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: pkg_{pre,post}inst misusage
On Saturday 24 December 2005 03:43, Duncan wrote: > Jason Stubbs posted <[EMAIL PROTECTED]>, excerpted > > below, on Sat, 24 Dec 2005 02:22:06 +0900: > > A quick patch makes symlinks handled similarly to regular files and > > solves the issue. I'll put it into testing unless anybody can come up > > with a reason not to. The case that will be broken by the patch is when > > two different packages install the same symlink. PackageA is > > installed, PackageB is installed, PackageB is uninstalled -> PackageA is > > broken. Does this case exist? > > Yikes! That's not going to remove /lib or /usr/lib or the like, for us on > amd64, where that's a symlink to lib64, will it? > > equery b /lib > [ Searching for file(s) /lib in *... ] > net-analyzer/macchanger-1.5.0-r1 (/lib) > sys-apps/baselayout-1.12.0_pre12 (/lib) > sys-boot/grub-0.97 (/lib) > sys-devel/gcc-4.0.2-r1 (/lib) > sys-devel/gcc-3.4.4-r1 (/lib) > sys-fs/device-mapper-1.01.05 (/lib) > sys-fs/lvm2-2.01.14 (/lib) > sys-fs/udev-078 (/lib) > sys-libs/glibc-2.3.6 (/lib) > > There's a similar, longer list, for /usr/lib. Obviously, not all of > those will own it as a symlink, but it is one, and if removing one happens > to remove the symlink... I'm not familiar with equery so I don't know what this output means. By the look of it, it is only a list of packages that own stuff in that directory. > Also consider the effect where a former dir is now a symlink or a former > symlink is now a dir. The recent xorg directory moves come to mind. With the patch I've done, recorded symlinks will continue to be ignored if the target is not a symlink. > You are /sure/ the new code won't screw anything of that sort up, right? > Maybe that's the reason nobody seems to have been around to know about. > It just sounds like it /could/ be dangerous to me. For some reason, I > don't like the idea of something that could hose a system that badly! =8^\ *Please* don't tell me you run ~arch. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
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]> > > > > wrote: > > | > That was my original thought when I started playing with it. I > > | > switched to postfix to make it more consistent with the way :slot > > | > and [use] restrictions work. *shrug* I guess it's down to whether > > | > you consider a > > | > > | 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? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
On Saturday 24 December 2005 02:57, Paul de Vrieze wrote: > On Friday 16 December 2005 18:54, Ciaran McCreesh wrote: > > On Fri, 16 Dec 2005 10:00:02 +0100 Danny van Dyk <[EMAIL PROTECTED]> > > > > wrote: > > | Just one remark: What about making the syntax a bit more familiar to > > | C++ users: > > | > > | ~ DEPENDS="gentoo-foo::foo-bar/baz-2.1" > > > > That was my original thought when I started playing with it. I switched > > to postfix to make it more consistent with the way :slot and [use] > > restrictions work. *shrug* I guess it's down to whether you consider a > > Do those already work then? I'd like to be able to use them. :slot and [use]? Not yet. I'm sure that once they do the shouts will be resounding across the globe such that it would not be possible for you to be unaware of it... ;) -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] pkg_{pre,post}inst misusage
On Saturday 24 December 2005 02:52, Harald van Dijk wrote: > On Sat, Dec 24, 2005 at 02:22:06AM +0900, Jason Stubbs wrote: > > Symlinks are handled within portage differently to regular files. Regular > > files get an mtime check and are removed if it matches. Symlinks don't > > get an mtime check (even thought the mtime is stored) and are only > > removed if the symlink's target doesn't exist. Hence, it seems to be this > > way by design. Why it's this way? Who knows. It's been that way for > > longer than anyone can remember which is why _it's so important that bugs > > get filed_. > > Honestly, I thought it was supposed to be like that, since > collision-protect also doesn't protect against packages overwriting > each other's symlinks (package A and package B can both create > /dummy -> bin without any problems from portage). As far as portage source goes, it is meant to be like that. But as far as portage source goes, installed package information isn't necessary for dep calculation (including depclean)... Most code has been reviewed and the major issues are known by at least one person, but there is still some code that hasn't suffered a close examination (yet alone reworking) such as the code that the above bug hits. > Do you want a bug report for that? Yes, please. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] pkg_{pre,post}inst misusage
On Saturday 24 December 2005 02:11, Zac Medico wrote:
> Harald van Dijk wrote:
> > Don't know if it's been reported as a portage bug, but this would show
> > it:
> >
> > KEYWORDS="~x86"
> > src_install() {
> > dodir /test
> > dosym /usr/bin /test
> > }
> >
> > When unmerging, portage won't remove /test/bin because its target still
> > exists.
>
> That is fixed in portage-2.0.53 (latest stable).
>
> http://bugs.gentoo.org/show_bug.cgi?id=59593
Similar characteristics but slightly different.
--
Jason Stubbs
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] pkg_{pre,post}inst misusage
On Friday 23 December 2005 22:13, Harald van Dijk wrote:
> On Fri, Dec 23, 2005 at 10:00:20PM +0900, Jason Stubbs wrote:
> > On Friday 23 December 2005 21:39, Harald van Dijk wrote:
> > > On Fri, Dec 23, 2005 at 08:31:06PM +0900, Jason Stubbs wrote:
> > > > On Friday 23 December 2005 20:19, Stefan Schweizer wrote:
> > > > > Well, you should know that those are because of portage bugs or
> > > > > some portage peculiarity, read the corresponding bugs for example
> > > > > for cups to find out more.
> > > >
> > > > Can you point me to a bug? There's no mention in the ChangeLog that I
> > > > can see nor in the ebuilds themselves...
> > >
> > > Bug #99375 is mentioned in the changelog for samba.
> >
> > Okay. It appears to be something related to symlinks. Can you show me the
> > bug assigned to portage that reports this and/or shows how to reproduce
> > it?
>
> Don't know if it's been reported as a portage bug, but this would show
> it:
>
> KEYWORDS="~x86"
> src_install() {
> dodir /test
> dosym /usr/bin /test
> }
>
> When unmerging, portage won't remove /test/bin because its target still
> exists.
Seeing that there's no bug filed for this, discussion can go here; that's no
existance of a portage bug is of itself no reason to put an ugly workaround
in the ebuilds themselves mind you.
Symlinks are handled within portage differently to regular files. Regular
files get an mtime check and are removed if it matches. Symlinks don't get an
mtime check (even thought the mtime is stored) and are only removed if the
symlink's target doesn't exist. Hence, it seems to be this way by design. Why
it's this way? Who knows. It's been that way for longer than anyone can
remember which is why _it's so important that bugs get filed_.
A quick patch makes symlinks handled similarly to regular files and solves the
issue. I'll put it into testing unless anybody can come up with a reason not
to. The case that will be broken by the patch is when two different packages
install the same symlink. PackageA is installed, PackageB is installed,
PackageB is uninstalled -> PackageA is broken. Does this case exist?
--
Jason Stubbs
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] pkg_{pre,post}inst misusage
On Friday 23 December 2005 21:39, Harald van Dijk wrote: > On Fri, Dec 23, 2005 at 08:31:06PM +0900, Jason Stubbs wrote: > > On Friday 23 December 2005 20:19, Stefan Schweizer wrote: > > > Well, you should know that those are because of portage bugs or some > > > portage peculiarity, read the corresponding bugs for example for cups > > > to find out more. > > > > Can you point me to a bug? There's no mention in the ChangeLog that I can > > see nor in the ebuilds themselves... > > Bug #99375 is mentioned in the changelog for samba. Okay. It appears to be something related to symlinks. Can you show me the bug assigned to portage that reports this and/or shows how to reproduce it? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] pkg_{pre,post}inst misusage
On Friday 23 December 2005 21:39, Harald van Dijk wrote: > On Fri, Dec 23, 2005 at 08:31:06PM +0900, Jason Stubbs wrote: > > On Friday 23 December 2005 20:19, Stefan Schweizer wrote: > > > Well, you should know that those are because of portage bugs or some > > > portage peculiarity, read the corresponding bugs for example for cups > > > to find out more. > > > > Can you point me to a bug? There's no mention in the ChangeLog that I can > > see nor in the ebuilds themselves... > > Bug #99375 is mentioned in the changelog for samba. It still doesn't explain why it's necessary. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] pkg_{pre,post}inst misusage
On Friday 23 December 2005 20:19, Stefan Schweizer wrote: > Well, you should know that those are because of portage bugs or some > portage peculiarity, read the corresponding bugs for example for cups > to find out more. Can you point me to a bug? There's no mention in the ChangeLog that I can see nor in the ebuilds themselves... -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] pkg_{pre,post}inst misusage
Here's what we have:
app-office/qhacc/qhacc-3.4.ebuild: [ -n "${PF}" ] && rm -rf
/usr/share/doc/${PF}
net-fs/samba/samba-3.0.14a-r2.ebuild: rm -rf
${ROOT}/usr/share/doc/${PF}
net-fs/samba/samba-3.0.14a-r3.ebuild: rm -rf
${ROOT}/usr/share/doc/${PF}
net-fs/samba/samba-3.0.20-r1.ebuild:rm -rf
${ROOT}/usr/share/doc/${PF}
net-fs/samba/samba-3.0.20a.ebuild: rm -rf
${ROOT}/usr/share/doc/${PF}
net-fs/samba/samba-3.0.20b.ebuild: rm -rf
${ROOT}/usr/share/doc/${PF}
net-print/cups/cups-1.1.23-r3.ebuild: rm -fR /usr/share/doc/${PF}
net-print/cups/cups-1.1.23-r4.ebuild: [ -n "${PN}" ] && rm -fR
/usr/share/doc/${PN}-*
net-print/cups/cups-1.1.23-r5.ebuild: [ -n "${PN}" ] && rm -fR
/usr/share/doc/${PN}-*
I'll let others do the yelling.
--
Jason Stubbs
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
On Friday 16 December 2005 14:57, Alec Warner wrote: > Ciaran McCreesh wrote: > > On Fri, 16 Dec 2005 00:36:54 -0500 Alec Warner <[EMAIL PROTECTED]> > > > > wrote: > > | emerge blar --repo=ciaranmssekritrepo > > | > > | This accomplishes the same thing, except I get to name the repo > > | whatever I wish, and you lose the ability to specify repositories in > > | DEPEND. > > > > ...and it stops you from being able to package.mask things in a given > > repository, > > Ideally there will be per-repo package.mask entries as well, since .mask > files are typically repository-based. Exactly. > > and it stops you from being able to stick to a given > > repository for world entries, and it stops you from being able to use > > /var/lib/portage/world sucks on the whole. The plan is to tag what repo a package came from into the installed package database if I understand correctly. > > it in all those zillion other locations where you can currently use a > > dep atom to do something useful. > > Anything in particular other than "those other useful things"? On Friday 16 December 2005 12:56, Ciaran McCreesh wrote: > DEPEND=">=foo-bar/baz-2.1::ciaranmssekritrepo" > > which would add a restriction that only packages in ciaranmssekritrepo > would be considered. This only works if the repository knows its own > identifier, however... I don't see the need for this. Resolution will the same repository to satisfy a package's dependencies where possible. If you just want to be able to state that a package from one repository needs packages from a different repository, wouldn't something like REPO_URI="mirror://gentoo/repo" suffice just as well without making a mess of the atom syntax? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP XX: Fix the GLEP process
On Wednesday 14 December 2005 06:16, Grant Goodyear wrote: > Jason Stubbs wrote: [Mon Dec 12 2005, 08:06:54PM CST] > > > The purpose of GLEPs is to coordinate several teams into providing an > > overall enhancement to Gentoo. However, the GLEP itself is written by > > a single person rather than a cooperative effort between the teams. > > You know, there's no reason that GLEPs need to be written by a single > person. It's often true, though, that it is a single person's idea, > initially at least. Definitely. Ideas usually are a single person's "eureka" even if it comes through discussion with others. > > Specification > > > > Rather than coming to the ML with a completed GLEP and then asking for > > feedback, a GLEP author should look at the teams involved and then > > select a solicit a member from each team to be responsible for that > > area of the GLEP. The GLEP author may represent any teams they belong > > to. > > Throwing out the initial GLEP amounts to the same thing, in my opinion, > since any interested parties are urged to provide feedback, and ideally > the next revision will include that feedback, either to accept it or > reject it. This is where it is falling down. The assumption is that somebody from each affected team happens to notice the post and have the time to reply before the GLEP goes too far. It also means that the goals and direction of the teams affected have no bearing on the initial revision of the GLEP. With the initial revision of the GLEP setting the direction in which it will head (or fizzle), the GLEP author is essentially handing tasks to various teams (which may conflict with their goals) if the initial revision draws enough support. > > Rationale > > > > Rather than doing lots of hard work and having it thrown away once it > > is found to be unacceptable by the teams involved, the teams involved > > share the hard work and come up with something acceptable to everybody > > right from the outset. > > Yes, of course, GLEP authors should talk to the folks who are likely to > be affected beforehand, but if they fail to do so then the GLEP process > is likely to be rather protracted for that GLEP. I have to admit that I > have no problem with people doing hard work for little gain, if that's > what people want to do. *Shrug* Why go through all that stress? Given GLEP 41, how much effort should infra need to put into defending why the tasks initially set out by the GLEP author are impractical? Is a single email enough? Is a battle with the GLEP author required if the GLEP author disagrees? That's assuming of course that a response was quick enough. It's not only the GLEP authors whom are doing extra unnecessary work. In addition as I missed out the signing off part from the inital post, should council members all be continually polling the lists for disagreement and marking it down in a notebook to be pulled out in time for when the GLEP is put to a vote? Or is it all just down to how convincingly the GLEP author speaks in the meeting where it is voted upon? Because there is no mechanism to ensure otherwise, the latter is inevitably the case. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Wednesday 14 December 2005 09:52, Ciaran McCreesh wrote: > On Wed, 14 Dec 2005 09:11:51 +0900 Jason Stubbs <[EMAIL PROTECTED]> > > wrote: > | newsdir="$(portageq envvar PORTDIR)/metadata/news" > | newsdir="$(portageq newsdir gentoo)" > | > | Both have one level of indirection. The first has two hard coded > | elements. The first has one. Where is the massive over-indirection? > | > | The second allows future changes. The first does not. Where does the > | specification come into it? All that would be needed is to allow a > | user a method to name overlays and it'd be useful straight off the > | bat. > > The former relies upon existing, widely used functionality together > with a well-defined path. The latter has some magic hard-coded name > voodoo (what's a 'gentoo'?) and is still stuck only supporting a single > location. What's a 'PORTDIR'? What's a 'metadata'? Outside of portage, these are also magic name voodoo. But I've grown tired of your imperfect circles. I think your design sucks and you think that my solution to making it not suck is too soon. The solution to that seems simple to me. Rather than have 'package manager' do anything, just have it provide hooks that will allow you to do your thing at the times you want. Good luck with solving the "news in overlays" bug when it comes in. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Wednesday 14 December 2005 08:54, Ciaran McCreesh wrote: > On Wed, 14 Dec 2005 08:44:39 +0900 Jason Stubbs <[EMAIL PROTECTED]> > > wrote: > | Modifications are required to portage anyway. Why postpone it until > | after several readers are written and force all of them become broken? > > Because there isn't a specification saying what the future changes to > Portage will be, so supporting said future changes straight off would > require a massively over-generalised, over-indirected solution. newsdir="$(portageq envvar PORTDIR)/metadata/news" newsdir="$(portageq newsdir gentoo)" Both have one level of indirection. The first has two hard coded elements. The first has one. Where is the massive over-indirection? The second allows future changes. The first does not. Where does the specification come into it? All that would be needed is to allow a user a method to name overlays and it'd be useful straight off the bat. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Wednesday 14 December 2005 07:12, Grant Goodyear wrote: > Jason Stubbs wrote: [Mon Dec 12 2005, 07:51:51PM CST] > > > | As I said already, there will immediately be a bug asking for overlay > > > | support. Portage already supports multiple in a form whether anybody > > > | likes it or not. How they are supported and how they will change > > > | should be of no concern to the glep. What should be of concern is > > > | establishing a robust API between the readers and portage such that > > > | future changes won't cause breakage. > > Wouldn't it suffice for the GLEP to simply have a statement that it will > query portage for a list of repositories, once there's a way to do that, > but until then the default repo will be assumed? Modifications are required to portage anyway. Why postpone it until after several readers are written and force all of them become broken? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP XX: Fix the GLEP process
On Tuesday 13 December 2005 11:58, Ciaran McCreesh wrote: > On Tue, 13 Dec 2005 11:39:49 +0900 Jason Stubbs <[EMAIL PROTECTED]> > > wrote: > | > So... If, hypothetically speaking, someone were to write a GLEP > | > saying "move developer documentation into the QA group, restructure > | > said documentation to this new format etc etc", and the QA group > | > were in favour, and the developer community in general were in > | > favour, and the council were in favour, and the people proposed by > | > the GLEP to manage the new documentation were in favour, but the > | > existing owners of the developer documentation were not, you're > | > saying that it shouldn't be approved? > | > | Yes. > > Unworkable. Your proposal would allow a small group of obstinate > developers to hold back progress. The problem here is that the council > isn't acting as a decent last line of quality control when the GLEP > authors fail to do their jobs properly. Your GLEP is trying to solve > the wrong thing... Wrong. I'll expand on the "Yes" now that I've got a few minutes... Actually, I'll turn that into a "No". I misread "the people proposed by the GLEP to manage the new documentation" in my rush to leave for work this morning. The existing owners don't matter to the GLEP. They can continue to maintain the existing documentation if they wish. If you didn't have new people to maintain the new documentation however... -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Tuesday 13 December 2005 11:48, Ciaran McCreesh wrote: > On Tue, 13 Dec 2005 11:39:14 +0900 Jason Stubbs <[EMAIL PROTECTED]> > > wrote: > | And how can that be adapted to work with overlays, completely > | ignoring the possibility of distinct repositories. Overlays is > | something that exists already and news support for them is a request > | that will appear as soon as news support is added. > > Overlays don't contain metadata directories There's nothing preventing this. > and don't get synced, As Zac pointed out, esync exists. > so they don't contain news items. Neither of the points above prevent an overlay from containing news items. > Supporting news from multiple sources is something that's tied to supporting > packages from multiple sources, which overlay doesn't permit. Overlays are used for getting packages from multiple sources every day. The only thing preventing them from supporting getting news from multiple sources is your stubborness against adding a single level of indirection - a level of indirection that has absolutely no cost to readers. > Fixing that would require fixing portage to support multiple repositories > rather than using overlay, which is an issue for a different GLEP. I'll say it again. It wouldn't require a GLEP because the changes wouldn't go beyond portage. At least they wouldn't if you'd allow portage to keep its internals internal. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Tuesday 13 December 2005 11:45, Andrew Muraco wrote: > Jason Stubbs wrote: > >On Tuesday 13 December 2005 11:22, Ciaran McCreesh wrote: > >>On Tue, 13 Dec 2005 11:17:30 +0900 Jason Stubbs <[EMAIL PROTECTED]> > >> > >>wrote: > >>| So what are you going to do? I asked already but you didn't answer. > >>| How are you going to find $PORTDIR/metadata/news? > >> > >>At present, by using portageq with a hardcoded suffix. If in the future > >>Portage introduces new functionality, then clients and the > >>specification can easily be updated to handle said functionality. > > > >And how can that be adapted to work with overlays, completely ignoring the > >possibility of distinct repositories. Overlays is something that exists > >already and news support for them is a request that will appear as soon as > >news support is added. > > Your Point is Moot ... Interesting use of capitals. > because an overlay (at present) is going to be exprimental software, or a repository from a non-English speaking community Gentoo site... > (unsupported offically anyways) and so you _should_ know what risks your > taking, except if your a new non-English-speaking user utilizing such a repository. > this GLEP is to warn you about supported updates/changes which you _need_ to > know about. This GLEP is about getting news regarding a set of ebuilds to the user. Making it only about the Gentoo supported tree serves no purpose. > Why should an overlay need to have news if the user has the consciensely > update and maintain it to begin it. Because they already support package.mask, thirdpartymirrors, eclasses and just about anything else that exists in the supported tree. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP XX: Fix the GLEP process
On Tuesday 13 December 2005 11:24, Ciaran McCreesh wrote: > On Tue, 13 Dec 2005 11:15:43 +0900 Jason Stubbs <[EMAIL PROTECTED]> > > wrote: > | A GLEP should list whom has been solicited and provide evidence that > | each has given their explicit approval of the GLEP. A GLEP without > | explicit approval of all teams involved cannot receive managerial > | approval. > > So... If, hypothetically speaking, someone were to write a GLEP saying > "move developer documentation into the QA group, restructure said > documentation to this new format etc etc", and the QA group were in > favour, and the developer community in general were in favour, and the > council were in favour, and the people proposed by the GLEP to manage > the new documentation were in favour, but the existing owners of the > developer documentation were not, you're saying that it shouldn't be > approved? Yes. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Tuesday 13 December 2005 11:22, Ciaran McCreesh wrote: > On Tue, 13 Dec 2005 11:17:30 +0900 Jason Stubbs <[EMAIL PROTECTED]> > > wrote: > | So what are you going to do? I asked already but you didn't answer. > | How are you going to find $PORTDIR/metadata/news? > > At present, by using portageq with a hardcoded suffix. If in the future > Portage introduces new functionality, then clients and the > specification can easily be updated to handle said functionality. And how can that be adapted to work with overlays, completely ignoring the possibility of distinct repositories. Overlays is something that exists already and news support for them is a request that will appear as soon as news support is added. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Tuesday 13 December 2005 11:11, Ciaran McCreesh wrote: > On Tue, 13 Dec 2005 10:51:51 +0900 Jason Stubbs <[EMAIL PROTECTED]> > > wrote: > | Without a list of future features, you think the best way to go must > | be the least agile? As Zac said, all that matters to keep full > | compatibility on the side of the readers is to add a level of > | indirection. All your reasoning above falls apart in the face of that > | simple *logical* request. > > Every problem can be solved by adding another layer of indirection, > except for the problem of having too many layers of indirection. This > layer you are proposing is not going to do anything useful. It's merely > adding indirection for the sake of it. There's no more need for this > than there is need for a two thousand line XML DTD which allows us to > specify the author's date of birth using an ancient Sumerian calendar. > > Come up with a full specification of how Portage will handle multiple > repositories, and get that specification agreed upon by the people who > will end up having to use it. *Then* come back and ask me to add in > more complexity. I'm not going to over-complicate things to deal with > random hypothetical half-baked speculation. So what are you going to do? I asked already but you didn't answer. How are you going to find $PORTDIR/metadata/news? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP XX: Fix the GLEP process
On Tuesday 13 December 2005 11:06, Jason Stubbs wrote: > Abstract > > The purpose of GLEPs is to coordinate several teams into providing an > overall enhancement to Gentoo. However, the GLEP itself is written by a > single person rather than a cooperative effort between the teams. > > > Motivation > > Recent GLEPs have attempted to force things on other teams. This just > doesn't work. > > > Specification > > Rather than coming to the ML with a completed GLEP and then asking for > feedback, a GLEP author should look at the teams involved and then select a > solicit a member from each team to be responsible for that area of the > GLEP. The GLEP author may represent any teams they belong to. A GLEP should list whom has been solicited and provide evidence that each has given their explicit approval of the GLEP. A GLEP without explicit approval of all teams involved cannot receive managerial approval. > Rationale > > Rather than doing lots of hard work and having it thrown away once it is > found to be unacceptable by the teams involved, the teams involved share > the hard work and come up with something acceptable to everybody right from > the outset. > > > Backwards Compatibility > > Nothing > > > Reference Implementation > > Just do it. > > > Copyright > > Public Domain -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] GLEP XX: Fix the GLEP process
Abstract The purpose of GLEPs is to coordinate several teams into providing an overall enhancement to Gentoo. However, the GLEP itself is written by a single person rather than a cooperative effort between the teams. Motivation Recent GLEPs have attempted to force things on other teams. This just doesn't work. Specification Rather than coming to the ML with a completed GLEP and then asking for feedback, a GLEP author should look at the teams involved and then select a solicit a member from each team to be responsible for that area of the GLEP. The GLEP author may represent any teams they belong to. Rationale Rather than doing lots of hard work and having it thrown away once it is found to be unacceptable by the teams involved, the teams involved share the hard work and come up with something acceptable to everybody right from the outset. Backwards Compatibility Nothing Reference Implementation Just do it. Copyright Public Domain -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Tuesday 13 December 2005 02:16, Ciaran McCreesh wrote: > On Mon, 12 Dec 2005 23:49:31 +0900 Jason Stubbs <[EMAIL PROTECTED]> > > wrote: > | No need for a glep as far as portage support goes anymore than Ciaran > | needs a glep to change or add syntax highlighting in vim. > > The difference is, Vim syntax scripts are well established, and there > aren't any design issues to solve. Multiple repository support clearly > *isn't* obvious, because the solution you've described is the wrong one. Blah, blah, blah. > | There doesn't need to be a debate. This whole proposal doesn't care > | about portage compatibility whatsoever and it's exactly this style of > | thinking that slows down portage development (which everybody loves > | to complain about so much). > > Sure it does. It cares about the way Portage is currently, and it cares > about any reasonable future Portage changes. Bullshit. > | As I said already, there will immediately be a bug asking for overlay > | support. Portage already supports multiple in a form whether anybody > | likes it or not. How they are supported and how they will change > | should be of no concern to the glep. What should be of concern is > | establishing a robust API between the readers and portage such that > | future changes won't cause breakage. > > Ok, give me a list of every single future enhancement to Portage and > I'll make sure the GLEP will be compatible with them. Without a list of future features, you think the best way to go must be the least agile? As Zac said, all that matters to keep full compatibility on the side of the readers is to add a level of indirection. All your reasoning above falls apart in the face of that simple *logical* request. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Monday 12 December 2005 18:30, Duncan wrote: > For example, if repository-id forms a part of the path and we define path > parsing now, then we are effectively defining legal characters for > repository-id now. This is only of concern to portage developers. > That's an entirely different glep, far out of scope and > reaching into other people's territory, limiting how that might be > implemented by defining a portion of the id-scope in an entirely unrelated > glep. No need for a glep as far as portage support goes anymore than Ciaran needs a glep to change or add syntax highlighting in vim. > Given how heated I've seen GLEP discussion get (and I'm not saying that's > /bad/, just a fact), I really can't blame Ciaran for attempting to keep > the scope of the proposal, and therefore the debate, down to exactly what > he's aiming to accomplish, without ending up getting into an entirely > /different/ debate about how he's limiting the future flexibility of the > multiple repo implementation. There doesn't need to be a debate. This whole proposal doesn't care about portage compatibility whatsoever and it's exactly this style of thinking that slows down portage development (which everybody loves to complain about so much). > Once there's a concrete proposal there to work with, then and only then, > he's saying (from my viewpoint), is it appropriate for consideration in > relation to the news proposal. Don't unnecessarily tie the two together, > complicating life for both. Let each be argued on its merits separately, > and when/if multiple repo is actually close enough to deployment that > there's some actual rules to work with, /then/ worry about fixing this to > match. As I said already, there will immediately be a bug asking for overlay support. Portage already supports multiple in a form whether anybody likes it or not. How they are supported and how they will change should be of no concern to the glep. What should be of concern is establishing a robust API between the readers and portage such that future changes won't cause breakage. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates
On Monday 12 December 2005 09:20, Ciaran McCreesh wrote: > On Mon, 12 Dec 2005 09:11:53 +0900 Jason Stubbs <[EMAIL PROTECTED]> > > wrote: > | Regardless of what you think about the current plans for multiple > | repository support, the details that readers will need to know wont > | change. > > Incorrect. Right now, readers should ignore news-blah.unread and only > pay attention to news.unread. Readers will have to be updated to deal > with multiple repositories whenever the multiple repositories GLEP is > approved. Incorrect. There needs to be no GLEP regarding multiple repository support in portage. There may need to be a GLEP regarding splitting up the portage tree into separate repositories, but that is nothing to do with the issue I'm talking about. > | > | Even before multiple respositories are properly supported, I > | > | guarantee bugs about support for this in portage overlays. With > | > | the above, we would be able to add that support. Without it, all > | > | we can do is put a big CANTFIX. > | > > | > Overlay is not the same as multiple repository support. > | > | There's no difference as far as readers go. > > Sure there is. there's no metadata/ directory in overlays. Again, why I really don't like this design. You're asking portage to do crap to support external tools without looking to provide compatibilty with future portages. How are you planning to find the metadata directory in the first place? > | Nope, which is why news.read shouldn't be specified. > > news.read is specified because there was demand for it the last time > around. It's staying specified because the reasons given were based > upon convincing use cases rather than random speculation. Can you show a use case that crosses several readers? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates
On Monday 12 December 2005 09:01, Ciaran McCreesh wrote: > On Mon, 12 Dec 2005 08:44:00 +0900 Jason Stubbs <[EMAIL PROTECTED]> > > wrote: > | Repositories will be user-labelled. However, all that readers need be > | concerned with is how to extract the repository name from the > | news.unread file and how to then resolve that to a directory name, > | regardless of how repositories are implemented. > > See, this is exactly why I'm not wanting to care about multiple repo > details at this point. There's no specification of how they work and > what exactly they're supposed to do, and to make matters worse the way > you seem to think they'll be handled is a really really bad way of > doing it. Regardless of what you think about the current plans for multiple repository support, the details that readers will need to know wont change. > | Even before multiple respositories are properly supported, I > | guarantee bugs about support for this in portage overlays. With the > | above, we would be able to add that support. Without it, all we can > | do is put a big CANTFIX. > > Overlay is not the same as multiple repository support. There's no difference as far as readers go. > | In that case, the data should probably not be in /var/lib/portage and > | definitely not specified in the GLEP. It has nothing to do with > | portage (the app) and isn't a requirement on readers. What if a > | reader wants to keep track of what date an item was read on? Or any > | other metadata? A new file would need to be created anyway due to > | format constrainst placed on news.read... > > Hrm. Does the GLEP need to cover how news readers that want to keep > track of whether or not the sysadmin was wearing pants last tuesday > should work too? Nope, which is why news.read shouldn't be specified. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates
On Monday 12 December 2005 02:43, Ciaran McCreesh wrote: > On Sun, 11 Dec 2005 13:32:05 +0900 Jason Stubbs <[EMAIL PROTECTED]> > > wrote: > | Repositories will definitely have a unique identifier. Perhaps it > | would be better to use the repository-identifing format from the > | beginning so that readers are forced to be forwards-compatible? > | Assuming the readers would then output the repository name, labeling > | it "gentoo" should work well... > > *shrug* If someone creates metadata/repository_id (or whatever), I'll > go with that. Otherwise, I'm not in favour of attempting to guess how > the thing will be implemented. Repositories will be user-labelled. However, all that readers need be concerned with is how to extract the repository name from the news.unread file and how to then resolve that to a directory name, regardless of how repositories are implemented. Even before multiple respositories are properly supported, I guarantee bugs about support for this in portage overlays. With the above, we would be able to add that support. Without it, all we can do is put a big CANTFIX. > | > When a news item is read, its name should be removed from the > | > ``news.unread`` file. News clients may add the name to a > | > ``news.read`` file in the same directory with the same file format. > | > | news.read should either be mandatory or not created at all. Should a > | user change from a reader that creates and uses the file to one that > | doesn't and then change back again the results will be unexpected. > > I'm not sure that that's the case. With a news to email forwarder, for > example, it wouldn't make sense to keep track of news.read. In that case, the data should probably not be in /var/lib/portage and definitely not specified in the GLEP. It has nothing to do with portage (the app) and isn't a requirement on readers. What if a reader wants to keep track of what date an item was read on? Or any other metadata? A new file would need to be created anyway due to format constrainst placed on news.read... -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates
On Sunday 11 December 2005 10:35, Ciaran McCreesh wrote: > Whenever relevant unread news items are found, the package manager will > create a file named ``/var/lib/portage/news/news.unread`` (if it does not > already exist) and append the news item identifier (eg > ``2005-11-01-yoursql-updates``) on a new line. > > .. Note:: Future changes to Portage involving support for multiple > repositories may require one news list per repository. Assuming > repositories have some kind of unique identifier, this file could be named > ``news-repoid.unread``. Repositories will definitely have a unique identifier. Perhaps it would be better to use the repository-identifing format from the beginning so that readers are forced to be forwards-compatible? Assuming the readers would then output the repository name, labeling it "gentoo" should work well... > When a news item is read, its name should be removed from the > ``news.unread`` file. News clients may add the name to a ``news.read`` file > in the same directory with the same file format. news.read should either be mandatory or not created at all. Should a user change from a reader that creates and uses the file to one that doesn't and then change back again the results will be unexpected. > * Important: there are 5 unread news items. > * Type emerge --help news to learn how to read news files. [...] > An ``eselect`` [#eselect]_ module shall be created as the 'suggested' > display tool; other display tools (for example, a news to email forwarder, > which would be ideal for users who sync on a ``cron``) are left as options > for those who desire them. By "suggested" you mean that it should be referenced in the news help? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] The deal with epkgmove
On Sunday 11 December 2005 00:56, Luca Barbato wrote: > svn so far was good but I don't know which big projects had it deployed. KDE uses subversion, depending on what you call big of course. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X porting: dependency changes
On Wednesday 07 December 2005 17:03, Donnie Berkholz wrote: > Donnie Berkholz wrote: > | As far as progress on this issue, we're looking into adopting glep 37 > | and creating a virtual/x11 ebuild to address this. > > I've just committed virtual/x11 to the tree. See > https://bugs.gentoo.org/show_bug.cgi?id=112896 if you run into any > problems with it. > > It won't work properly with macos yet because they use a "fake" package, > so they'll have to hang on to virtual/x11 in the profiles. It should work if the listed package matches what the macos profiles have in package.provided... > I plan to remove the virtual/x11 definition from base/virtuals in a > couple of days, because this should provide a full (and non-broken) > replacement. This can be easily tested in advance by adding the following: # cat /etc/portage/profile/virtuals virtual/x11 -* -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [gentoo-portage-dev] .53, .54 and beyond...
On Tuesday 06 December 2005 21:37, Alec Warner wrote: > Jason Stubbs wrote: > > On Tuesday 06 December 2005 11:17, Ned Ludd wrote: > > > On Mon, 2005-12-05 at 23:06 +0900, Jason Stubbs wrote: > > > > Okay, new suggestion. > > > > > > > > Postpone the cache rewrite from above. Have only the minimal mods > > > > necessary to fix the PORT_LOGDIR/tee bug. Include the other two as is. > > > > That would be 2.0.54 as per the attached patch. Get that out soon and > > > > get trunk out masked at around the same time. As soon as 2.0.54 goes > > > > stable put trunk into ~arch. However, instead of ~arch meaning > > > > "regression fixes only" we could just limit it to "minor changes only" > > > > (ie. no big refactorings, rewrites or similar high risk changes) until > > > > it is time to stable it. > > > > > > I think it would be wise to reconsider the cache fixes. I know you have > > > been away from irc for a while now and have missed the daily events, > > > but most of the people we have interacted with are expecting the cache > > > updates in .54 (alot of people complaining about the hanging at 50%) > > > > Call me wrong, but I'm feeling that the constant pulling and pushing on > > IRC causes many misjudgements. > > No I agree with you here, I just wanted reasoning because now I have > this ML thread to refer people to :p Of course, there's enough pushing and pulling on the ML here to provide food for thought. :) Ok, I've come to a conclusion and that conclusion is: We have way too much indecisiveness. I'm not sure if that's my fault or not - am I meant to be decisive? My guess is that if I were to seriously propose that question there'd be a lot of indecision about it. ;) So I'm going to make a decision and offer until Friday (Saturday in my time) for opposers to solidify and state any opposition. If there's no solid opposition, Saturday I will put current trunk into ~arch as 2.1_beta20051210. I will also post on the 2.0.53 bug that fixes are available for the ldconfig bug and the tee bug stating that we'd like to also add trunk's cache subsystem to 2.0.54 and that dependening on the next council meeting(?) the SHA1 enabling as well. Doing it this way will make the ~arch users happy straight away. If we look at it as our responsibility to get fixes and new functionality into ~arch then our jobs done and we can get back to business. As for stable users? If arch teams are willing to selectively choose what fixes they want backported to stable (when they're not prepared to move the ~arch version into stable) things will go much smoother. Of course, it would still be our responsibility to get those things backported and assert some confidence that it is working. However, once the requested fixes are backported all that needs to be done is put out the patched stable version with ~arch keywords and then leave it up to the arch teams again. Except for the slight extra burden on (which I believe many would actually find to be a blessing), it should be a win-win situation. Cross-posting to -dev@ so that some arch people can comment. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] emerge -e question Was: GCC-3.4 will be marked stable in ~1 hour on x86
On Saturday 03 December 2005 21:47, Duncan wrote: > Mark Loeser posted <[EMAIL PROTECTED]>, excerpted > > below, on Fri, 02 Dec 2005 16:55:23 -0500: > > [1] http://www.gentoo.org/proj/en/base/x86/gcc-upgrading-guide.xml > > Reading this reminds me of a question I've had since I tried emerge -eav > world last time: > > When portage merges, it stops the emerge process, updates its metadata or > whatever, then restarts the process. With the -e in there, at least here, > it reissued the same command over again, thereby restarting the process > from the beginning and of course, upon getting to portage, looping yet > again! This is incorrect. Portage should only restart if the version that was merged does not match the internally recorded version. There was one or two releases that had an incorrect internal version but not for at least a year. However, if the version has changed and portage does restart itself then any packages listed before portage will be merged again. > Maybe it was because I was using -KuD also, to remerge/upgrade from binary > packages? (Hard disk trouble, I was remerging the binary packages to > bring up2date an old installation snapshot.) Perhaps you were using one of the broken versions? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] manpages that requires dependencies
On Monday 28 November 2005 00:05, Jason Stubbs wrote: > 3) FEATURES="noman" is dropped in favour of USE="man" or USE="manpages" > > In light of the above requirements and the fact that dyn_* will likely be > moved into the tree down the track, #3 seems to be the best in my mind. > Similarly, it would solve the previously discussed problems related to > FEATURES="test". I'd be very interested in people's thoughts on this. The more I think about it, the more I think it's the most appropriate solution. Nothing in FEATURES="noman nodoc noinfo test" affects portage whatsoever other than "noinfo" which (only recently) prevents emerge from regenerating info indexes. That one could be handled by a hook (although not yet available) and the rest could easily be switched to USE flags. Anybody see any flaws? Anybody want (shudders) a GLEP? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] manpages that requires dependencies
On Sunday 27 November 2005 23:50, Diego 'Flameeyes' Pettenò wrote: > On Sunday 27 November 2005 15:39, Jason Stubbs wrote: > > Core packages or not, they are all broken. When the requirement came up, > > the respective maintainers should have spoken up so that a proper > > solution could be found. When are the quick hacks going to stop? :| > > Is my mail enough as a speak-up for finding a proper solution? :P Err.. Apologies. I has forgotten that you were the one to start the thread. :( -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] manpages that requires dependencies
On Sunday 27 November 2005 23:43, Jakub Moc wrote:
> 27.11.2005, 15:39:48, Jason Stubbs wrote:
> > On Sunday 27 November 2005 22:09, Ned Ludd wrote:
> >> On Sun, 2005-11-27 at 07:58 -0500, Ned Ludd wrote:
> >> > On Fri, 2005-11-25 at 12:46 +0200, Marius Mauch wrote:
> >> > > Except that no{man,info,doc} are on the to-die list anyway.
> >> >
> >> > They are very valuable features and quite easy to use without mucking
> >> > with INSTALL_MASK. I'm against this change without some justification.
> >>
> >> further investigation shows that you can't simply get rid of these as
> >> several core ebuilds use the feature to control the creation of
> >> packages. A quick grep shows that several ebuilds do stuff like.
> >> has noman FEATURES && do_stuff
> >>
> >> openssl/glibc/gcc/dhcp/boa/gdb to name a few that take advantage of the
> >> no{man,info,doc} FEATURES= already.
> >
> > Core packages or not, they are all broken. When the requirement came up,
> > the respective maintainers should have spoken up so that a proper
> > solution could be found. When are the quick hacks going to stop? :|
>
> I can't see why exactly do we need to get rid of useful features? :-(
Nobody said anything about getting rid of the features. The only thing that
has been stated is that FEATURES="noman" cannot be relied upon to mean that
portage won't install man pages or vice-versa.
There are three possibilities that I can see:
1) FEATURES="noman" becomes FEATURES="man"
2) FEATURES="noman" is dropped in favour of INSTALL_MASK="/usr/share/man"
3) FEATURES="noman" is dropped in favour of USE="man" or USE="manpages"
In light of the above requirements and the fact that dyn_* will likely be
moved into the tree down the track, #3 seems to be the best in my mind.
Similarly, it would solve the previously discussed problems related to
FEATURES="test".
--
Jason Stubbs
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] manpages that requires dependencies
On Sunday 27 November 2005 23:50, Diego 'Flameeyes' Pettenò wrote: > On Sunday 27 November 2005 15:39, Jason Stubbs wrote: > > Core packages or not, they are all broken. When the requirement came up, > > the respective maintainers should have spoken up so that a proper > > solution could be found. When are the quick hacks going to stop? :| > > Is my mail enough as a speak-up for finding a proper solution? :P No because you haven't listed any requirements beyond those that solar has already pointed out. :P -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] manpages that requires dependencies
On Sunday 27 November 2005 22:09, Ned Ludd wrote:
> On Sun, 2005-11-27 at 07:58 -0500, Ned Ludd wrote:
> > On Fri, 2005-11-25 at 12:46 +0200, Marius Mauch wrote:
> > > Except that no{man,info,doc} are on the to-die list anyway.
> >
> > They are very valuable features and quite easy to use without mucking
> > with INSTALL_MASK. I'm against this change without some justification.
>
> further investigation shows that you can't simply get rid of these as
> several core ebuilds use the feature to control the creation of
> packages. A quick grep shows that several ebuilds do stuff like.
> has noman FEATURES && do_stuff
>
> openssl/glibc/gcc/dhcp/boa/gdb to name a few that take advantage of the
> no{man,info,doc} FEATURES= already.
Core packages or not, they are all broken. When the requirement came up, the
respective maintainers should have spoken up so that a proper solution could
be found. When are the quick hacks going to stop? :|
--
Jason Stubbs
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Removal of auto-use in portage-2.0.54
On Sunday 27 November 2005 01:48, Henrik Brix Andersen wrote:
> On Sat, Nov 26, 2005 at 05:12:45PM +0200, Marius Mauch wrote:
> > As I said earlier, we'd like to get rid of the nasty auto-use feature,
> > including the support for the USE_ORDER variable. Right now we intend
> > this for 2.0.54 (might not be the final version number) unless there are
> > major objections to it.
>
> What will happen to the USE flags currently in use.defaults when this
> is removed?
It will turn off unless it is enabled somewhere else.
> Perhaps some of them be moved to the profiles instead?
This is more of a releng/basesystem question rather than a portage question.
Makes no difference to me as a user as I have USE="-* ..." in make.conf. ;)
> I'm mostly concerned about the 'udev' USE flag. Some packages rely on
> this to be able to function correctly on an udev enabled system.
> Since udev seems to be the default choice for our default-linux
> profiles, it would make sense to also set USE=udev in those profiles?
Message logging will come in at the same time so it might be better to do
something like:
portageq has_version ${ROOT} sys-fs/udev && use !udev && (
ewarn "You have udev installed but do not the udev USE flag enabled."
ewarn "${PN} might behave incorrectly."
)
Except with better bash style of course.. But that's just what I'd do. Once
proper logging goes in, it'd be a good idea for policies on things like this
to be developed.
--
Jason Stubbs
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multi hash support in portage - status
On Saturday 26 November 2005 11:12, Marius Mauch wrote: > On Thu, 24 Nov 2005 01:04:32 +0100 > > Marius Mauch <[EMAIL PROTECTED]> wrote: > > Would you rather have now the ability to create multi-hash digests and > > Manifests with the result of a short and mid-term larger portage tree > > (in the long term the format will be phased out hopefully) or rather > > wait for Manifest2 support (which will definitely include multi hash > > support)? > > Ok, so far two votes for now and one vote for later, unless this > changes significantly I'll ask the council to add the decision to the > agenda for its next meeting (sorry, just don't want to be the bad guy > here ;) /me adds a vote for later to even it up. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] manpages that requires dependencies
On Friday 25 November 2005 08:58, Ciaran McCreesh wrote: > Of course, if FEATURES were in the USE expand list, you could use > ! features_noman ? ( ) ... All the way up until FEATURES="noman" is changed to FEATURES="man"... -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multi hash support in portage - status
On Thursday 24 November 2005 10:07, Marius Mauch wrote: > On Thu, 24 Nov 2005 09:49:20 +0900 > > Jason Stubbs <[EMAIL PROTECTED]> wrote: > > On Thursday 24 November 2005 09:32, Marius Mauch wrote: > > > On Thu, 24 Nov 2005 01:04:32 +0100 > > > > > > Marius Mauch <[EMAIL PROTECTED]> wrote: > > > > Ok I have three modifications that are pending to go into portage: > > > > - The first simply enables creation of SHA1 checksums (and others > > > > if implemented like with the second mod), if you want to try it > > > > yourself see the attached patch. > > > > Looking through CVS, this was supported in at least > > portage-2.0.51_rc10 right? This implies that the only versions that > > will have problems are 2.0.50-r11 and under? If so, they've already > > got the cascaded profile problem so breaking things a little more > > won't hurt much. ;) > > > > Seriously though, those that can't handle the new format would have > > to do what? Regenerate digests for sandbox and portage and then > > emerge each of them with --oneshot? Am I missing anything else there? > > Nope, not missing anything. Thought I said it, compability isn't a > reason to hold this up anymore, only asking if people want multi-hashes > now at the expense of a bigger tree when Manifest2 comes along. I'm referring to portage-2.0.50 and below. What exactly needs to be done by those few that are still using it to upgrade to a better portage after it dies on finding SHA1 sums in portage's digest? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
