Re: [gentoo-user] What happens with masked packages?
On Sun, 26 Feb 2006 20:26:54 -0500 John J. Foster [EMAIL PROTECTED] wrote: | That's a very true statement, and part of the attraction of Gentoo. | But your comment about most users (at least of this distro) not | having the slightest clue what's best for them is totally off base, | (except, perhaps, where I'm concerned ;-)). Hah. Try doing bug wrangling for a week and you might change that opinion. Anyway, part of the point of using a distribution is that it spares you from having to know what's best for you. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-user] What happens with masked packages?
Ciaran McCreesh wrote: Anyway, part of the point of using a distribution is that it spares you from having to know what's best for you. That's a little harsh, Ciaran. I did the linux from scratch thing. Had a lot of fun with it. Enjoyed being down in the bowels of the linux system and the total control over what was installed. I knew what was best for me, I knew what my requirements were and built the box to satisfy those requirements. Then after a few weeks of tracking freshmeat daily to see what updates I needed to download and apply manually, I stumbled upon gentoo and have been a happy gentoo'er since. I never lost sight of what was best for me, what my requirements were. I merely had to alter my processes to incorporate the automated nature that gentoo offers (what a relief that was ;-) Your statement is probably true for all of the binary distribution folks. But I doubt that you'll get many from this crowd that would say that we want or expect the gentoo team to know what's best for [us]. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] What happens with masked packages?
On Mon, 27 Feb 2006 12:33:46 -0500 Dave Nebinger [EMAIL PROTECTED] wrote: | Your statement is probably true for all of the binary distribution | folks. But I doubt that you'll get many from this crowd that would | say that we want or expect the gentoo team to know what's best for | [us]. What, you think that everyone here knows exactly which version of gcc, with which patches and which corresponding binutils to use? You think that everyone here knows exactly which versions of db they do and do not need installed? You think that everyone here knows which kernel headers they should be using and in what way they should be patched? Most of our users don't have a clue about those questions. Heck, most of our devs don't either. Figuring all that stuff out correctly is a hell of a lot of work. One of the major reasons for using Gentoo over LFS is that someone else has done said work for you. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-user] What happens with masked packages?
On Sat, 25 Feb 2006 13:34:28 -0600 Boyd Stephen Smith Jr. [EMAIL PROTECTED] wrote: | | ~arch means a package is a candidate for going into arch after | | further testing, if said testing does not turn up new bugs. This | | means that both the ebuild *and* the package should be likely | | to be stable. | | | | So, betas shouldn't ever be ~arch? Or is your definition of | | stable broad enough to include betas? | | Entirely dependent on the upstream. I've had Vim beta releases in | ~arch, for example, because I'm confident in upstream's ability to | do beta releases without screwing up. | | So, it's based on the collective opinion of the gentoo developers? | Wouldn't it be better to put that in the hands of the gentoo user? Absolutely not. If there's one thing we've established over the years, it's that the vast majority of our users don't have the slightest clue what's best for them in terms of package stability. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-user] What happens with masked packages?
On 2006-02-25 23:16:36 -0600 (Sat, Feb), Boyd Stephen Smith Jr. wrote: So, it's based on the collective opinion of the gentoo developers? Wouldn't it be better to put that in the hands of the gentoo user? IMHO it already is. It's called PORTAGE_OVERLAY. Again, hard to do automatically. Wheras, if I could just set ACCEPT_UPSTREAM=BETA I'd get all the betas. Or I could use package.upstream and but in kde-extra/kaffeine ALPHA and get anything assigned more than a snapshot number for that package. (Instead of manually checking after each sync to see if there's a new, masked version.) In 'man 5 ebuild' I see: Atom Versions It is nice to be more specific and say that only certain versions of atoms are acceptable. Note that versions must be combined with a prefix (see below). Hence you may add a version number as a postfix to the base: sys-apps/sed-4.0.5 sys-libs/zlib-1.1.4-r1 net-misc/dhcp-3.0_p2 Versions are normally made up of two or three numbers separated by periods, such as 1.2 or 4.5.2. This string may be followed by a character such as 1.2a or 4.5.2z. Note that this letter is not meant to indicate alpha, beta, etc... status. For that, use the optional suffix; either _alpha, _beta, _pre (pre-release), _rc (release candidate), or _p (patch). This means for the 3rd pre-release of a package, you would use something like 1.2_pre3. I suppose that you could prepare a script that builds your /etc/portage files to unmask packages with _beta versions, or with any other criteria contained in ebuild. -- No virus found in this outgoing message. Checked by grep -i virus $MESSAGE Trust me. pgpC6oflyDCXS.pgp Description: PGP signature
Re: [gentoo-user] What happens with masked packages?
On Sunday 26 February 2006 06:16, Boyd Stephen Smith Jr. wrote: Again, hard to do automatically. Wheras, if I could just set ACCEPT_UPSTREAM=BETA I'd get all the betas. Or I could use package.upstream and but in kde-extra/kaffeine ALPHA and get anything assigned more than a snapshot number for that package. (Instead of manually checking after each sync to see if there's a new, masked version.) How exactly is is you want this to work. I mean for example gaim-2.0.0_beta2-r1 is a beta and it's very unstable (well, it crashed occasionally for me). In order to get it you need to put it in package.unmask and package.keywords. Do you want to have to put it package.upstream too? Or don't you want it to be masked even though it's very unstable? Should package.upstream override package.mask? -- Bo Andresen -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] What happens with masked packages?
On Sunday 26 February 2006 11:06, Bo Andresen [EMAIL PROTECTED] wrote about 'Re: [gentoo-user] What happens with masked packages?': On Sunday 26 February 2006 06:16, Boyd Stephen Smith Jr. wrote: Again, hard to do automatically. Wheras, if I could just set ACCEPT_UPSTREAM=BETA I'd get all the betas. Or I could use package.upstream and but in kde-extra/kaffeine ALPHA and get anything assigned more than a snapshot number for that package. (Instead of manually checking after each sync to see if there's a new, masked version.) How exactly is is you want this to work. My proposal at this point, would be for an additional restriction on packages based on a new UPSTREAM variable in the ebuild itself, ACCEPT_UPSTREAM variable in make.conf / the environment, and the package.upstream file in /etc/portage. These would be directly analogous to KEYWORDS, ACCEPT_KEYWORDS, and package.keywords, as would its interaction with package.mask. I mean for example gaim-2.0.0_beta2-r1 is a beta and it's very unstable (well, it crashed occasionally for me). In order to get it you need to put it in package.unmask and package.keywords. For any specific package, I'd have to know why it's in package.mask and why it's ~ARCH instead of ARCH. If something like my proposal were actually implemented, there would be some transitional period that you might see a _beta ebuild in package.mask or marked as ~ARCH simply because it's beta, but that would go away with new ebuilds (well, not entirely...) Hazarding a guess for this package, I'd say it would be removed from package.mask but the ebuild would retain the ~ARCH instead of ARCH (likely, the ebuild is also unstable, but I don't know.) Do you want to have to put it package.upstream too? Yes, you'd have to add 'net-im/gaim BETA' to package.upstream if you wanted all gaim betas. Many users would probably be better served with '=net-im/gaim-2* BETA'. You could remove it from your package.unmask because it wouldn't have to be masked by package.unmask (the default ACCEPT_UPSTREAM would not include BETA). Or don't you want it to be masked even though it's very unstable? I would like package.mask reserved for migration issues, package suite issues, and ebuilds and packages that destructively interfere with other packages. I'm guessing that the gaim beta doesn't have any of these issues, so it would not be in package.mask but would be labeled UPSTREAM=BETA. Should package.upstream override package.mask? No, it would only change your ACCEPT_UPSTREAM for certain packages, similar to the way package.keywords changes your ACCEPT_KEYWORDS. At this point, I'd really like to take this theoretical discussion off the the general user list; I doubt many users will be interested. I haven't done any coding work on this proposal or even began writing a GLEP, so this is all theory without any action at this point. I'm absolutely willing and eager to discuss things further via private email. My email address is in the from header, unmunged. I just don't want to waste the bandwidth of users that aren't interested in my vapor-proposal. -- If there's one thing we've established over the years, it's that the vast majority of our users don't have the slightest clue what's best for them in terms of package stability. -- Gentoo Developer Ciaran McCreesh -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] What happens with masked packages?
On Sun, Feb 26, 2006 at 02:40:31PM -0600, Boyd Stephen Smith Jr. wrote: At this point, I'd really like to take this theoretical discussion off the the general user list; I doubt many users will be interested. I haven't done any coding work on this proposal or even began writing a GLEP, so this is all theory without any action at this point. Please don't take this off list, as I think this is quite relevant here. festus -- I contend we are both atheists, I just believe in one fewer gods than you do. When you understand why you dismiss all the other possible gods, you will understand why I dismiss yours. ...Stephen F Roberts pgpdQTz1xGGNS.pgp Description: PGP signature
Re: [gentoo-user] What happens with masked packages?
On Sun, Feb 26, 2006 at 04:11:08PM +, Ciaran McCreesh wrote: Absolutely not. If there's one thing we've established over the years, it's that the vast majority of our users don't have the slightest clue what's best for them in terms of package stability. Excuse me my friend, but I switched to Gentoo because of this attitude with every other distro I've moved away from !!! festus -- I contend we are both atheists, I just believe in one fewer gods than you do. When you understand why you dismiss all the other possible gods, you will understand why I dismiss yours. ...Stephen F Roberts pgpjKGx32wM68.pgp Description: PGP signature
Re: [gentoo-user] What happens with masked packages?
On Sun, 26 Feb 2006 18:29:52 -0500 John J. Foster [EMAIL PROTECTED] wrote: | On Sun, Feb 26, 2006 at 04:11:08PM +, Ciaran McCreesh wrote: | Absolutely not. If there's one thing we've established over the | years, it's that the vast majority of our users don't have the | slightest clue what's best for them in terms of package stability. | | Excuse me my friend, but I switched to Gentoo because of this | attitude with every other distro I've moved away from !!! The distro people are right. The difference between Gentoo and most other distributions is that we make it easier for you to override our decisions, should you feel the need. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-user] What happens with masked packages?
On Sunday 26 February 2006 21:40, Boyd Stephen Smith Jr. wrote: How exactly is is you want this to work. My proposal at this point, would be for an additional restriction on packages based on a new UPSTREAM variable in the ebuild itself, ACCEPT_UPSTREAM variable in make.conf / the environment, and the package.upstream file in /etc/portage. I read your previous posts about this as that you wanted it to be easier to get beta versions but what you want is in fact the exact opposite - further restriction. Now I get it. -- Bo Andresen -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] What happens with masked packages?
On Sunday 26 February 2006 18:15, Bo Andresen [EMAIL PROTECTED] wrote about 'Re: [gentoo-user] What happens with masked packages?': On Sunday 26 February 2006 21:40, Boyd Stephen Smith Jr. wrote: How exactly is is you want this to work. My proposal at this point, would be for an additional restriction on packages based on a new UPSTREAM variable in the ebuild itself, ACCEPT_UPSTREAM variable in make.conf / the environment, and the package.upstream file in /etc/portage. I read your previous posts about this as that you wanted it to be easier to get beta versions but what you want is in fact the exact opposite - further restriction. Now I get it. Well, it would make it easier by moving them /out/ of package.mask and putting them in a classification similar to KEYWORDS. Then, to get all the betas my heart desires I can simply set ACCEPT_UPSTREAM=BETA, instead of manually pawing through package.mask to add them all to package.unmask. In particular, I update my system regularly with emerge -avtuND world. This won't give me any notification that betas are available but masked. I'd like to configure my system so that any new betas of kaffeine, kmplayer, ktorrent, and the nsplugins for kaffeine and kmplayer would be installed with having to regularly check on them myself. I'm imaging the default provided by the base profile would be ACCEPT_UPSTREAM=RELEASE BUG_FIX SECURITY_FIX so that packages with UPSTREAM=BETA (or HEAD, SNAPSHOT, ALPHA, PRE_RELEASE, RELEASE_CANDIDATE, alia al) would not be installed. (Until you changes your ACCEPT_UPSTREAM in make.conf or edit /etc/portage/package.upstream) I'd like upstream stability more cleanly separated from ebuild stability. Ciaran did clarify the roles of the various keywords and the global and profile-provided package.masks; from my experience I couldn't see the degree of separation that is intended -- dismissing the few abuses that are still in the portage tree. I still think my system would be better, but I'm biased. :) -- If there's one thing we've established over the years, it's that the vast majority of our users don't have the slightest clue what's best for them in terms of package stability. -- Gentoo Developer Ciaran McCreesh -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] What happens with masked packages?
On Mon, Feb 27, 2006 at 12:11:02AM +, Ciaran McCreesh wrote: On Sun, 26 Feb 2006 18:29:52 -0500 John J. Foster [EMAIL PROTECTED] wrote: | On Sun, Feb 26, 2006 at 04:11:08PM +, Ciaran McCreesh wrote: | Absolutely not. If there's one thing we've established over the | years, it's that the vast majority of our users don't have the | slightest clue what's best for them in terms of package stability. | | Excuse me my friend, but I switched to Gentoo because of this | attitude with every other distro I've moved away from !!! The distro people are right. The difference between Gentoo and most other distributions is that we make it easier for you to override our decisions, should you feel the need. Ciarin, That's a very true statement, and part of the attraction of Gentoo. But your comment about most users (at least of this distro) not having the slightest clue what's best for them is totally off base, (except, perhaps, where I'm concerned ;-)). \rant mode off\ festus -- I contend we are both atheists, I just believe in one fewer gods than you do. When you understand why you dismiss all the other possible gods, you will understand why I dismiss yours. ...Stephen F Roberts pgp0rwcrcasYD.pgp Description: PGP signature
Re: [gentoo-user] What happens with masked packages?
On Sunday 26 February 2006 18:57, Boyd Stephen Smith Jr. wrote: My proposal at this point, would be for an additional restriction on packages based on a new UPSTREAM variable in the ebuild itself, ACCEPT_UPSTREAM variable in make.conf / the environment, and the package.upstream file in /etc/portage. Stephen and I have talked about this before. The real fleshed out idea is meant to be for a user that might want to follow a package as it moves from alpha-beta-release. While the overall stability of the system might be compromised by globally adding an ACCEPT_UPSTREAM=BETA an individual may be willing to make that compromise to test new applications and provide upstream bug reports before a package has made it to final release. I read your previous posts about this as that you wanted it to be easier to get beta versions but what you want is in fact the exact opposite - further restriction. Now I get it. I don't envision it as further restriction, instead it's a way to add seperation of ebuild/software stability. Imagine that I have a package that is in early alpha state and very unstable. However the ebuild for that package does not hurt the system, it's proper and conforms to portage and plays nicely. Under the current system if my ebuild was added to portage it would be masked with package.mask. Under the new system it would not be in package.mask, instead a user would have to set ACCEPT_UPSTREAM=ALPHA or set mypackage ALPHA in package.upstream. This also facilitates cvs ebuilds nicely by not having to hard mask everything, but instead making the user choose the system's level of stability. Of course the defaults would be sane, but then the user could override it globally or locally to each package. This would clean package.mask up and make it purely for misbehaving ebuilds. I'm imaging the default provided by the base profile would be ACCEPT_UPSTREAM=RELEASE BUG_FIX SECURITY_FIX so that packages with UPSTREAM=BETA (or HEAD, SNAPSHOT, ALPHA, PRE_RELEASE, RELEASE_CANDIDATE, alia al) would not be installed. (Until you changes your ACCEPT_UPSTREAM in make.conf or edit /etc/portage/package.upstream) Let's take a real life example of the cloudiness of the current situation. If you run ~arch right now and update your system it will pull a new kernel in even if that kernel is a release candidate. The ebuild is clean and installs properly and is not in package.mask, however if you don't want release candidate kernels there isn't an easy way to do it and only allow released version. Under the new system the kernel ebuilds would still be handled the same way (not placed into package.mask), but the user wouldn't get a release candidate kernel unless they say ACCEPT_UPSTREAM=RELEASE_CANDIDATE or set the kernel up that way in package.upstream. Another example that sticks out in my head. In the run up to KDE 3.5 I wanted to follow all the ALPHA, BETA and RC releases so I could file bug reports and make the final version better. There wasn't an easy way to do this and the list of packages to unmask was enourmous. Somewhere near beta2 all the ebuils were good, so it could be cleanly merged, but you had to go through the unmask dance. Under the new system once the ebuilds were clean, they would move out of package.mask and any user with the appropriate ACCEPT_UPSTREAM/package.upstream settings could test the new KDE. If there's one thing we've established over the years, it's that the vast majority of our users don't have the slightest clue what's best for them in terms of package stability. -- Gentoo Developer Ciaran McCreesh I can't believe he said that! What he might have meant is that we should provide sane defaults to our users so newcomers don't get hosed systems due to us requiring intimate knowledge of the system. While we shouldn't make unsafe policies at the global level we should allow advanced users to do as they please. -- Zac Slade [EMAIL PROTECTED] ICQ:1415282 YM:krakrjak AIM:ttyp99 -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] What happens with masked packages?
On Fri, 24 Feb 2006 14:57:43 -0600 Boyd Stephen Smith Jr. [EMAIL PROTECTED] wrote: | ~arch means a package is a candidate for going into arch after | further testing, if said testing does not turn up new bugs. This | means that both the ebuild *and* the package should be likely to be | stable. | | So, betas shouldn't ever be ~arch? Or is your definition of stable | broad enough to include betas? Entirely dependent on the upstream. I've had Vim beta releases in ~arch, for example, because I'm confident in upstream's ability to do beta releases without screwing up. | -* means the package is in some way architecture or hardware | independent (e.g. a binary only package), and so will only run on | archs that are explicitly listed. | | So, I guess glibc-2.3.6-r3.ebuild is using -* incorrectly? Probably. | Any package setting KEYWORDS=-* and nothing else is abusing -*, | and will flag a warning on the QA checkers. | | You mean like gcc-4.1.0_pre20060219.ebuild? Yyyyup. The -* abuse is one of the many things on QA's list of stuff we want to get fixed. However, it's considered extremely low priority on existing packages. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-user] What happens with masked packages?
On Saturday 25 February 2006 12:57, Ciaran McCreesh [EMAIL PROTECTED] wrote about 'Re: [gentoo-user] What happens with masked packages?': On Fri, 24 Feb 2006 14:57:43 -0600 Boyd Stephen Smith Jr. [EMAIL PROTECTED] wrote: | ~arch means a package is a candidate for going into arch after | further testing, if said testing does not turn up new bugs. This | means that both the ebuild *and* the package should be likely to be | stable. | | So, betas shouldn't ever be ~arch? Or is your definition of stable | broad enough to include betas? Entirely dependent on the upstream. I've had Vim beta releases in ~arch, for example, because I'm confident in upstream's ability to do beta releases without screwing up. So, it's based on the collective opinion of the gentoo developers? Wouldn't it be better to put that in the hands of the gentoo user? The -* abuse is one of the many things on QA's list of stuff we want to get fixed. However, it's considered extremely low priority on existing packages. As it should be, since there are well-known user work-arounds. -- Boyd Stephen Smith Jr. [EMAIL PROTECTED] ICQ: 514984 YM/AIM: DaTwinkDaddy -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] What happens with masked packages?
On 2006-02-25 13:34:28 -0600 (Sat, Feb), Boyd Stephen Smith Jr. wrote: So, betas shouldn't ever be ~arch? Or is your definition of stable broad enough to include betas? Entirely dependent on the upstream. I've had Vim beta releases in ~arch, for example, because I'm confident in upstream's ability to do beta releases without screwing up. So, it's based on the collective opinion of the gentoo developers? Wouldn't it be better to put that in the hands of the gentoo user? IMHO it already is. It's called PORTAGE_OVERLAY. -- No virus found in this outgoing message. Checked by grep -i virus $MESSAGE Trust me. pgpsUzjzY3U8t.pgp Description: PGP signature
Re: [gentoo-user] What happens with masked packages?
On Saturday 25 February 2006 17:47, Mariusz Pękala [EMAIL PROTECTED] wrote about 'Re: [gentoo-user] What happens with masked packages?': On 2006-02-25 13:34:28 -0600 (Sat, Feb), Boyd Stephen Smith Jr. wrote: So, betas shouldn't ever be ~arch? Or is your definition of stable broad enough to include betas? Entirely dependent on the upstream. I've had Vim beta releases in ~arch, for example, because I'm confident in upstream's ability to do beta releases without screwing up. So, it's based on the collective opinion of the gentoo developers? Wouldn't it be better to put that in the hands of the gentoo user? IMHO it already is. It's called PORTAGE_OVERLAY. Again, hard to do automatically. Wheras, if I could just set ACCEPT_UPSTREAM=BETA I'd get all the betas. Or I could use package.upstream and but in kde-extra/kaffeine ALPHA and get anything assigned more than a snapshot number for that package. (Instead of manually checking after each sync to see if there's a new, masked version.) -- Boyd Stephen Smith Jr. [EMAIL PROTECTED] ICQ: 514984 YM/AIM: DaTwinkDaddy -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] What happens with masked packages?
On Wed, 22 Feb 2006 16:12:33 -0600 Boyd Stephen Smith Jr. [EMAIL PROTECTED] wrote: | From what I understand this is incorrect. package.mask, -*, and the | ~ARCH (and occasionally, -ARCH) keywords are supposed to indicate | the /ebuild/'s stability, not the upstream stability. Not exactly. Top level package.mask means there's something wrong with the upstream package. Often this is because it's a beta release. It can also be used for major ebuild changes. Profile package.mask means a package that's usually OK on a particular architecture has to be masked on particular profiles. The canonical example is gcc on archs where 32/64 bit is handled via subprofiles. ~arch means a package is a candidate for going into arch after further testing, if said testing does not turn up new bugs. This means that both the ebuild *and* the package should be likely to be stable. No keyword means it's unknown whether a package will work on a particular arch, because no-one has tested it. -arch means a package will not work on a particular arch. -* means the package is in some way architecture or hardware independent (e.g. a binary only package), and so will only run on archs that are explicitly listed. Any package setting KEYWORDS=-* and nothing else is abusing -*, and will flag a warning on the QA checkers. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-user] What happens with masked packages?
First of all, thanks for the reply and clarification. It's always good to hear from an actual developer when I start ranting. [I know I could always go pick a fight on gentoo-dev, but I'll reserve that for when I've got a justifiable beef, and not just a half-baked rant. ;)] On Friday 24 February 2006 11:31, Ciaran McCreesh [EMAIL PROTECTED] wrote about 'Re: [gentoo-user] What happens with masked packages?': Top level package.mask means there's something wrong with the upstream package. Often this is because it's a beta release. It can also be used for major ebuild changes. Okay, that's clearer, though I still wish beta was more cleanly separated from broken -- While betas generally are broken to some degree, they are purposely put out there so users will file the bugs upstream. While I suppose the comments in package.mask do provide a method for determining when it's safe to unmask a beta, it's difficult to automatically handle betas. Under my system you just set ACCEPT_UPSTREAM=BETA and you get beta packages without the broken ones, automatically. ~arch means a package is a candidate for going into arch after further testing, if said testing does not turn up new bugs. This means that both the ebuild *and* the package should be likely to be stable. So, betas shouldn't ever be ~arch? Or is your definition of stable broad enough to include betas? -* means the package is in some way architecture or hardware independent (e.g. a binary only package), and so will only run on archs that are explicitly listed. So, I guess glibc-2.3.6-r3.ebuild is using -* incorrectly? Any package setting KEYWORDS=-* and nothing else is abusing -*, and will flag a warning on the QA checkers. You mean like gcc-4.1.0_pre20060219.ebuild? Sorry if I come off too critically [1]. I do see an unclean separation of upstream-stable vs. ebuild-stable in the portage system and I'd like to see it fixed, but everyday I appreciate how much work goes in to maintaining the portage tree and improving the gentoo experience. -- Boyd Stephen Smith Jr. [EMAIL PROTECTED] ICQ: 514984 YM/AIM: DaTwinkDaddy [1] Also, sorry I'm just a squeaky wheel instead of actively trying to fix the problem, I know there are more constructive things to do (GLEP, experimental portage backages, etc.) besides rant on the user list. -- gentoo-user@gentoo.org mailing list
[gentoo-user] What happens with masked packages?
Hello, I'm running an amd64 Gentoo (but this is not a specific amd64 question) and have installed a few ~amd64 masked packages - and some work amzingly well. So I googled for information as to where I might report success, so that they might be unmasked, but didn't find that info. Where - and how - should I report masked packages that work? Thierry -- The problem with the world is stupidity. Not saying there should be a capital punishment for stupidity, but why don't we just take the safety labels off of everything and let the problem solve itself? Frank Zappa -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] What happens with masked packages?
Thierry de Coulon wrote: Where - and how - should I report masked packages that work? You don't need to report success. There are teams of folks who 'bless' the packages into unmasked status when they feel they are ready. Your lack of reporting a bug is an indication that there is nothing to block the package from being promoted. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] What happens with masked packages?
On Wednesday 22 February 2006 21.02, Dave Nebinger wrote: Thierry de Coulon wrote: Where - and how - should I report masked packages that work? You don't need to report success. There are teams of folks who 'bless' the packages into unmasked status when they feel they are ready. Your lack of reporting a bug is an indication that there is nothing to block the package from being promoted. Thanks. Does not seem to me to be the best solution, though: if a package is masked, many users won't install it, so what's the absence of bug report indicating? In my case, the funny thing is: DVDRIP is not masked and does not work. Acidrip is masked and works like a charm. Let's hope that the blessing folks find out. Thierry -- The problem with the world is stupidity. Not saying there should be a capital punishment for stupidity, but why don't we just take the safety labels off of everything and let the problem solve itself? Frank Zappa -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] What happens with masked packages?
On Wednesday 22 February 2006 13:55, Thierry de Coulon [EMAIL PROTECTED] wrote about '[gentoo-user] What happens with masked packages?': I'm running an amd64 Gentoo (but this is not a specific amd64 question) and have installed a few ~amd64 masked packages - and some work amzingly well. Glad to hear it. I run entirely ~amd64 on my desktop and things work like a charm. So I googled for information as to where I might report success, so that they might be unmasked, but didn't find that info. No need to report success. If the maintainer is happy with the ebuild and there are no bugs filed for 30 days (or is it 90?) the package will be moved from testing (~arch) to stable (arch). Remember that these keywords are (generally) for the ebuild, and doesn't indicate how well the product provided by upstream works. -- Boyd Stephen Smith Jr. [EMAIL PROTECTED] ICQ: 514984 YM/AIM: DaTwinkDaddy -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] What happens with masked packages?
Thierry de Coulon wrote: Thanks. Does not seem to me to be the best solution, though: if a package is masked, many users won't install it, so what's the absence of bug report indicating? You can also file a bug report that a package which you thing is stable is still masked. In this case a developer should examine the requested package a little bit deeper. pgpD80sSAaUlU.pgp Description: PGP signature
Re: [gentoo-user] What happens with masked packages?
On Wednesday 22 February 2006 14:38, Thierry de Coulon [EMAIL PROTECTED] wrote about 'Re: [gentoo-user] What happens with masked packages?': Thanks. Does not seem to me to be the best solution, though: if a package is masked, many users won't install it, so what's the absence of bug report indicating? I hate how emerge / portage calls a missing keyword masked. It's really not the same thing as being in package.mask (so called hard-masked). In package.mask there is something decidedly broken, be it compatibility or otherwise. But, there's often nothing wrong with testing besides being new. ~ARCH is testing, ARCH is stable. It's like debian's stable/testing/unstable braches, but more fluid. On gentoo, packages are generally moved from testing to stable individually, with batch moves reserved for suites (like KDE or Gnome) or packages with migration issues. We have a number of users just on this mailing list that run testing systems all day long. We encounter more bugs than stable users, but that's alright because we /want/ to test things, and have no fear of submitting a bug. Now, if you want to fire off automated 'emerge -u world's every night, I'd suggest staying away from testing. So far, the system has mostly worked. I *would* like to see some changes, but mainly due to the fact that ~ARCH and package.mask are used for two purposes right now. See rant below. In my case, the funny thing is: DVDRIP is not masked and does not work. Acidrip is masked and works like a charm. Is the DVD:Rip ebuild doing something incorrectly, or is it just a poor package from upstream? In the former case, please file a bug at bugs.gentoo.org. In the latter, a bug can be filed, but it's more likely to get attention in upstream rather than at bugs.gentoo.org. I'm not sure /exactly/ what you want from your ripping program, but I'd check out ANDREW (ANDREW's Not a DVD Ripping and Encoding Wizard) from the FSF. Sooner or later I'm gonna write an ebuild for that sucka. (Only my rant and .sig follow, so no need to scroll if you don't want my opinion.) rant Right now, we see package.mask, -*, and sometimes even ~ARCH being used to indicate instability from upstream. For example, the gcc-4.1 ebuilds work perfectly, yet are marked -*. As another example, there was a bit of time when the KDE 3.5_beta2 ebuilds worked fine (and were ~ARCH) but they were package.mask'ed. From what I understand this is incorrect. package.mask, -*, and the ~ARCH (and occasionally, -ARCH) keywords are supposed to indicate the /ebuild/'s stability, not the upstream stability. The problem is, we can't simply drop the practice of package.mask or -*'ing things like gcc-4.1 or beta versions of a DE that a good number of gentoo users work with everyday. Too many systems would break if such ebuilds were marked STABLE with no indication that *you are installing software that might not work*. What's really needed is a separate field indicating upstream classification, something similar to ACCEPT_KEYWORDS but indicating not the stability / behavior of the ebuild, but of the package from upstream. This would help both users (they can choose the test ebuilds, upstream, or both) and developers (they don't have to ever think Was upstream broken or was the ebuild? when they see a *-). We could also do away with the perpetually masked cvs / - versions. It would be something like ACCEPT_UPSTREAM=BETA in make.conf where you might also have HEAD, SNAPSHOT, ALPHA, RELEASE_CANDIDATE, RELEASE, BUG_FIX, SECURITY_FIX instead of BETA; Also there would either be special logic for HEAD or an additional flag in the ebuild for always upgrade, even to same version, but I suppose that's a different matter. Of course, this would require significant work, and may not even be something the gentoo developers would be interested in. (The existing system seems to work OK, even if it's not ideal.) But, that's my two cents, hopefully I won't feel the need to bore the entire mailing list with this again for a while. (Or maybe I'll get off my digital butt and learn enough about portage to fix it myself, or at least file a GLEP) /rant -- Boyd Stephen Smith Jr. [EMAIL PROTECTED] ICQ: 514984 YM/AIM: DaTwinkDaddy -- gentoo-user@gentoo.org mailing list
