Re: [gentoo-dev] Re: Change policy about live ebuilds
> On Sun, 21 Nov 2010, Alexis Ballier wrote: >> Also, for an ebuild with empty KEYWORDS, repoman will not indicate >> any problems with dependencies. > by default with a p.mask it doesnt either. Yes, but it has an option to enable it, whereas there isn't such an option for empty KEYWORDS. Ulrich
Re: [gentoo-dev] Re: GCC 4.5 unmasking tomorrow
is emerging sys-devel/gcc-4.5.1-r1 enough? thanks! -alessandro- Here i am, A young man, A crashing computer program, Here is a pen, write out my name. On Sun, Nov 21, 2010 at 14:14, Duncan <1i5t5.dun...@cox.net> wrote: > Mike Frysinger posted on Sun, 21 Nov 2010 14:57:50 -0500 as excerpted: > >> well, not quite. the way we agreed in the past was to not revbump the >> masked package, but once it was unmasked, we revbump it just once at >> that point. > > User-side ++ > > -- > Duncan - List replies preferred. No HTML msgs. > "Every nonfree program has a lord, a master -- > and if you use the program, he is your master." Richard Stallman > > >
Re: [gentoo-dev] Re: Change policy about live ebuilds
On Sunday 21 November 2010 19:47:34 Ulrich Mueller wrote: > > On Sun, 21 Nov 2010, Markos Chandras wrote: > > If the majority of the devs ( at least of those who participate to > > this thread ) is positive, then I will commit a patch to devmanual > > and possibly migrate the cvs&svn sources pages into a single one. > > Just for the record, I'm not in favour of such a change. > > So far, the policy has been that KEYWORDS would reflect the stability > of the ebuild, whereas package.mask would indicate that the upstream > package is deemed unstable. Why should live ebuilds be handled in a > different way? I see more keywords as reflecting the "level of testing of the package in our tree", which is zero for a live ebuild. > Also, for an ebuild with empty KEYWORDS, repoman will not indicate any > problems with dependencies. by default with a p.mask it doesnt either. A.
Re: [gentoo-dev] Can't the Portage be an efficient guy?
On 11/21/2010 05:27 PM, Delian Xu wrote: > For example, > Sometime when you install or update a package, it would failed by 'masked' > reasons and you have to deal with the failure > (Though you can use a auto-unmask tool here). However, users would hope > the Portage / emerge system give an option > to chose Y or N like this: >xxx lines of information and warnings about masked package, >Would you like to unmask the package and continue the installation? > [Y/N]: > > This would be much better for all users. (It is just an example.) In portage-2.1.9 there's a new --autounmask option. If you like it you can use EMERGE_DEFAULT_OPTS to enable it by default in make.conf. There are a couple of related feature requests that I should also mention. Bug #258371 [1] requests the ability to automatically satisfy USE dependencies. This would be similar to having --autounmask enabled by default, but without requiring you to edit your config files. Bug #345775 [2] requests an option for --autounmask to automatically edit config files. Difficulty in resolving USE dependencies is a very common complaint. For example, I recently dealt with a user venting similar frustration to yours on bug #345175 [3]. It's worth mentioning that that there may be a lot of cases in which we can use IUSE defaults to satisfy reverse USE dependencies, without add adding any bloat. I would encourage ebuild developers to look for opportunities like this whenever adding USE dependencies. [1] http://bugs.gentoo.org/show_bug.cgi?id=258371 [2] http://bugs.gentoo.org/show_bug.cgi?id=345775 [3] http://bugs.gentoo.org/show_bug.cgi?id=345175 -- Thanks, Zac
[gentoo-dev] Can't the Portage be an efficient guy?
Hi there, * Almost every time* when I try to update packages to the latest snapshot, it would failed by these errors or those errors, I have to say that's really too too bad. Isn't this a big problem of the Portage that users have to hack it every time? * Gentoo is a system with great freedom, but that doesn't mean to be bad user experience.* So I'd like to suggest Gentoo-developers devote minds and move on to develop the Portage, that should do more things and fix issues much more smartly and friendly. I think most Gentoo-users would hope it to be self-moving further. For example, Sometime when you install or update a package, it would failed by 'masked' reasons and you have to deal with the failure (Though you can use a auto-unmask tool here). However, users would hope the Portage / emerge system give an option to chose Y or N like this: xxx lines of information and warnings about masked package, Would you like to unmask the package and continue the installation? [Y/N]: This would be much better for all users. (It is just an example.) I think A freedom OS with good user experience would help users get to know things and make the choice easily and quickly, without dozens of errors/problems every time. If the Portage can work as well as APT on Debian, then Gentoo can be a good choice for lots of Linux-Users, but not only Gentoo-developers or a spot of users that like to hack the OS every day. As a developer on Linux, I'd like to vote for Gentoo, that is vivid and compendious. But As a Gentoo user, I would say it gets a bad user experience*, *the most problems is not the UI, but the Portage is still too weak and feebleness.* * Thanks, Delian* *
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2010-11-21 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2010-11-21 23h59 UTC. Removals: dev-tex/mpm 2010-11-16 09:08:19 fauli media-gfx/gimp-lqr-plugin 2010-11-18 12:50:44 phajdan.jr Additions: net-zope/zope-applicationcontrol2010-11-15 13:24:50 arfrever net-zope/zope-app-applicationcontrol2010-11-15 13:34:53 arfrever net-zope/zope-app-locales 2010-11-15 13:40:03 arfrever app-emacs/auto-complete 2010-11-16 18:55:16 ulm x11-plugins/vicious 2010-11-16 23:51:34 wired app-emacs/undo-tree 2010-11-17 18:17:24 tomka dev-libs/eina 2010-11-18 12:29:04 tommy media-plugins/gimp-lqr 2010-11-18 12:46:35 phajdan.jr dev-libs/eet2010-11-18 13:26:19 tommy media-libs/evas 2010-11-18 13:34:47 tommy dev-libs/ecore 2010-11-18 13:54:42 tommy dev-libs/embryo 2010-11-18 14:05:32 tommy media-libs/edje 2010-11-18 14:08:52 tommy dev-libs/e_dbus 2010-11-18 14:14:59 tommy dev-libs/efreet 2010-11-18 14:22:52 tommy dev-libs/eeze 2010-11-18 14:25:30 tommy games-puzzle/sdl-jewels 2010-11-18 20:04:02 mr_bones_ app-misc/tmux-mem-cpu-load 2010-11-18 23:30:13 wired gnome-extra/gnome-color-manager 2010-11-19 13:26:03 flameeyes sys-auth/ykclient 2010-11-20 00:28:32 flameeyes dev-perl/Test-Trap 2010-11-20 09:22:58 jlec -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: dev-tex/mpm,removed,fauli,2010-11-16 09:08:19 media-gfx/gimp-lqr-plugin,removed,phajdan.jr,2010-11-18 12:50:44 Added Packages: net-zope/zope-applicationcontrol,added,arfrever,2010-11-15 13:24:50 net-zope/zope-app-applicationcontrol,added,arfrever,2010-11-15 13:34:53 net-zope/zope-app-locales,added,arfrever,2010-11-15 13:40:03 app-emacs/auto-complete,added,ulm,2010-11-16 18:55:16 x11-plugins/vicious,added,wired,2010-11-16 23:51:34 app-emacs/undo-tree,added,tomka,2010-11-17 18:17:24 dev-libs/eina,added,tommy,2010-11-18 12:29:04 media-plugins/gimp-lqr,added,phajdan.jr,2010-11-18 12:46:35 dev-libs/eet,added,tommy,2010-11-18 13:26:19 media-libs/evas,added,tommy,2010-11-18 13:34:47 dev-libs/ecore,added,tommy,2010-11-18 13:54:42 dev-libs/embryo,added,tommy,2010-11-18 14:05:32 media-libs/edje,added,tommy,2010-11-18 14:08:52 dev-libs/e_dbus,added,tommy,2010-11-18 14:14:59 dev-libs/efreet,added,tommy,2010-11-18 14:22:52 dev-libs/eeze,added,tommy,2010-11-18 14:25:30 games-puzzle/sdl-jewels,added,mr_bones_,2010-11-18 20:04:02 app-misc/tmux-mem-cpu-load,added,wired,2010-11-18 23:30:13 gnome-extra/gnome-color-manager,added,flameeyes,2010-11-19 13:26:03 sys-auth/ykclient,added,flameeyes,2010-11-20 00:28:32 dev-perl/Test-Trap,added,jlec,2010-11-20 09:22:58 Done.
[gentoo-dev] Re: Re: Change policy about live ebuilds
Il giorno dom, 21/11/2010 alle 16.22 +0100, Sebastian Pipping ha scritto: > > Why does KEYWORDS="" on live ebuilds make users angry? Before I started tinderboxing we had a number of live ebuilds in tree – and I don't mean simply "fetch the given rev out of svn", but real, - type live ebuilds – with ~arch keywords. That's what I went on to mask, at the time. -- Diego Elio Pettenò — “Flameeyes” http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/
Re: [gentoo-dev] Re: Change policy about live ebuilds
On Sun, Nov 21, 2010 at 10:10:32PM +, Duncan wrote: > Ryan Hill posted on Sun, 21 Nov 2010 13:30:15 -0600 as excerpted: > > > On Sun, 21 Nov 2010 19:05:44 + > > Markos Chandras wrote: > > > >> > Isn't that the point? People should be discouraged in every way not > >> > to use live ebuilds. I'd add a third if we had one. :) > >> > > >> Actually not. Users are already familiar with the - concept so > >> there is no point to add extra obstacles in their way. I am trying to > >> find out corner cases where double masking makes sense. Otherwise it > >> makes no sense to me. Actually the majority of users get confused when > >> a package is double masked. Just drop by forums etc and you will see :) > > > > Again, that's the point. If you can't figure out how to get around a > > double mask then you have no business installing live ebuilds. > > As a user who regularly uses certain live ebuilds (and contrasting SP), > strongly agreed. If the double-masking is confusing them, they're better > off sticking with standard versioned ebuilds as they're demonstrably not > up to dealing with other difficulties which might arise with a live > package and Gentoo doesn't need the extra bug noise. Double-masking for > live ebuilds in the main tree thus seems to me to be the best policy. > I thought I'd chip in as well. I wouldn't consider myself a poweruser, but more and more often I find myself preferring to use the live ebuilds. When I first attempted at using live ebuilds I knew next to nothing and didn't quite understand the double masking. Some time later I know use a fair few live ebuilds. Had I understood the masking (more so than being able to remove it) back then, then I would have used them. But I reckon it's a good idea to have the double masking and confuse those that don't know enough. I'd say keep the double masking. Better that than the bugs it would probably produce, and the breakage it could produce. -- Zeerak Waseem
Re: [gentoo-dev] Re: Change policy about live ebuilds
On Sun, Nov 21, 2010 at 10:10:32PM +, Duncan wrote:
> As a user who regularly uses certain live ebuilds (and contrasting SP),
> strongly agreed. If the double-masking is confusing them, they're better
> off sticking with standard versioned ebuilds as they're demonstrably not
> up to dealing with other difficulties which might arise with a live
> package and Gentoo doesn't need the extra bug noise. Double-masking for
> live ebuilds in the main tree thus seems to me to be the best policy.
The way I see it there are already several layers of masking you can
control in package.keywords. You can unmask a specific version of a
package, unmask all ~arch versions of a package, or unmask all versions
regardless of keywords which is what ** does.
I think that if we document somewhere that ** will install live ebuilds
and that if users do that they really get to keep the pieces we are
covered. I think that if a user is playing around with ACCEPT_KEYWORDS
and /etc/portage/package.{keywords,mask,unmask}, especially if they are
installing live ebuilds, they should be comfortable with
troubleshooting.
William
pgpiHegdIcZBO.pgp
Description: PGP signature
Re: [gentoo-dev] Re: Change policy about live ebuilds
> On Sun, 21 Nov 2010, Markos Chandras wrote: > If the majority of the devs ( at least of those who participate to > this thread ) is positive, then I will commit a patch to devmanual > and possibly migrate the cvs&svn sources pages into a single one. Just for the record, I'm not in favour of such a change. So far, the policy has been that KEYWORDS would reflect the stability of the ebuild, whereas package.mask would indicate that the upstream package is deemed unstable. Why should live ebuilds be handled in a different way? Also, for an ebuild with empty KEYWORDS, repoman will not indicate any problems with dependencies. Ulrich
Re: [gentoo-dev] Re: Change policy about live ebuilds
On Sun, Nov 21, 2010 at 09:22:24PM +, Markos Chandras wrote: > On Sun, Nov 21, 2010 at 01:30:15PM -0600, Ryan Hill wrote: > > On Sun, 21 Nov 2010 19:05:44 + > > Markos Chandras wrote: > > > > > > Isn't that the point? People should be discouraged in every way not to > > > > use > > > > live ebuilds. I'd add a third if we had one. :) > > > > > > > > But yes, if I had to pick only one I'd go with dropping keywords over > > > > package.mask. In fact it looks like I have some live ebuilds in the > > > > tree > > > > that do exactly that. > > > > > > > Actually not. Users are already familiar with the - concept so there > > > is no point to add extra obstacles in their way. I am trying to find out > > > corner cases where double masking makes sense. Otherwise it makes no > > > sense to me. Actually the majority of users get confused when a package > > > is double masked. Just drop by forums etc and you will see :) > > > > Again, that's the point. If you can't figure out how to get around a > > double mask then you have no business installing live ebuilds. > > > > But this is getting off topic. If you want to change the policy to > > recommend > > dropping keywords rather than using package.mask then I support it. > > package.mask has the disadvantage that it's too easy to accidentally unmask > > live versions with >=. And nothing stops someone from doing both if they > > want. > > > > > > -- > > fonts, gcc-porting, it makes no sense how it makes no sense > > toolchain, wxwidgets but i'll take it free anytime > > @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 > > 0662 > > If the majority of the devs ( at least of those who participate to this > thread ) is positive, then I will commit a patch to devmanual and > possibly migrate the cvs&svn sources pages into a single one. Count me in on this policy change. I think that double masking is a pain as well. I would agree that we might want to document somewhere that if users are using "**" in package.keywords they really get to keep the pieces, since they will be installing live ebuilds. William pgpPgMm2d9YfD.pgp Description: PGP signature
[gentoo-dev] Re: GCC 4.5 unmasking tomorrow
Mike Frysinger posted on Sun, 21 Nov 2010 14:57:50 -0500 as excerpted: > well, not quite. the way we agreed in the past was to not revbump the > masked package, but once it was unmasked, we revbump it just once at > that point. User-side ++ -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
[gentoo-dev] Re: Change policy about live ebuilds
Ryan Hill posted on Sun, 21 Nov 2010 13:30:15 -0600 as excerpted: > On Sun, 21 Nov 2010 19:05:44 + > Markos Chandras wrote: > >> > Isn't that the point? People should be discouraged in every way not >> > to use live ebuilds. I'd add a third if we had one. :) >> > >> Actually not. Users are already familiar with the - concept so >> there is no point to add extra obstacles in their way. I am trying to >> find out corner cases where double masking makes sense. Otherwise it >> makes no sense to me. Actually the majority of users get confused when >> a package is double masked. Just drop by forums etc and you will see :) > > Again, that's the point. If you can't figure out how to get around a > double mask then you have no business installing live ebuilds. As a user who regularly uses certain live ebuilds (and contrasting SP), strongly agreed. If the double-masking is confusing them, they're better off sticking with standard versioned ebuilds as they're demonstrably not up to dealing with other difficulties which might arise with a live package and Gentoo doesn't need the extra bug noise. Double-masking for live ebuilds in the main tree thus seems to me to be the best policy. For the main tree, anyway. In overlays, I'd say it's up to the overlay maintainers, as in many cases, the overlays are overtly experimental already, and just the fact that it's in the overlay not the main tree has added a barrier of its own. It could also be argued whether the general main tree policy should be "maintainer's discretion" or not. Obviously, it's that way already in practice. Should we tighten up QA or make the policy overtly "maintainer's discretion"? -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Re: IUSE="minimal" seems like a bad idea
On Sun, 21 Nov 2010 21:51:04 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > The suggestion as I read it is to have, for instance, a "vim-minimal" > flag (IOW, one per package), the idea being to prevent someone from > sticking minimal in their global USE flags and having all sorts of > stuff "break" as a result. That's pretty pointless. Most of those packages use the 'minimal' flag in a similar fashion, and your solution simply complicates things for users. If you wanted to remove 'minimal' from global USE flag list -- ok, I don't mind that. But don't require ebuild authors to use stupid names for their local flags just because you assume some users may misuse them. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Re: Change policy about live ebuilds
On Sun, 21 Nov 2010 19:05:44 + Markos Chandras wrote: > > Isn't that the point? People should be discouraged in every way not to use > > live ebuilds. I'd add a third if we had one. :) > > > > But yes, if I had to pick only one I'd go with dropping keywords over > > package.mask. In fact it looks like I have some live ebuilds in the tree > > that do exactly that. > > > Actually not. Users are already familiar with the - concept so there > is no point to add extra obstacles in their way. I am trying to find out > corner cases where double masking makes sense. Otherwise it makes no > sense to me. Actually the majority of users get confused when a package > is double masked. Just drop by forums etc and you will see :) Again, that's the point. If you can't figure out how to get around a double mask then you have no business installing live ebuilds. But this is getting off topic. If you want to change the policy to recommend dropping keywords rather than using package.mask then I support it. package.mask has the disadvantage that it's too easy to accidentally unmask live versions with >=. And nothing stops someone from doing both if they want. -- fonts, gcc-porting, it makes no sense how it makes no sense toolchain, wxwidgets but i'll take it free anytime @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-dev] Re: IUSE="minimal" seems like a bad idea
Ciaran McCreesh posted on Sun, 21 Nov 2010 12:34:10 + as excerpted: > On Sat, 20 Nov 2010 23:44:05 -0500 > Matt Turner wrote: >> matts...@sempron /usr/portage $ egrep -l 'IUSE=.*minimal' `find -name >> '*.ebuild'` >> >> ^ shows lots of ebuilds with IUSE="minimal". Instead of having a >> minimal use flag for these packages, shouldn't we have, possibly local, >> use flags for whatever feature(s) the minimal flag turns off? > > For vim, which is where I believe the minimal flag originated, you'd > have to have twenty or thirty individual flags for the vim features in > question, and many of them are interdependent. The suggestion as I read it is to have, for instance, a "vim-minimal" flag (IOW, one per package), the idea being to prevent someone from sticking minimal in their global USE flags and having all sorts of stuff "break" as a result. So each package would still have its single flag, but they'd be different for each package, to prevent "accidents" like the above. Then again, this arguably belongs in the "you get to keep the pieces" category... -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Re: Change policy about live ebuilds
On Sun, Nov 21, 2010 at 01:30:15PM -0600, Ryan Hill wrote: > On Sun, 21 Nov 2010 19:05:44 + > Markos Chandras wrote: > > > > Isn't that the point? People should be discouraged in every way not to > > > use > > > live ebuilds. I'd add a third if we had one. :) > > > > > > But yes, if I had to pick only one I'd go with dropping keywords over > > > package.mask. In fact it looks like I have some live ebuilds in the tree > > > that do exactly that. > > > > > Actually not. Users are already familiar with the - concept so there > > is no point to add extra obstacles in their way. I am trying to find out > > corner cases where double masking makes sense. Otherwise it makes no > > sense to me. Actually the majority of users get confused when a package > > is double masked. Just drop by forums etc and you will see :) > > Again, that's the point. If you can't figure out how to get around a > double mask then you have no business installing live ebuilds. > > But this is getting off topic. If you want to change the policy to recommend > dropping keywords rather than using package.mask then I support it. > package.mask has the disadvantage that it's too easy to accidentally unmask > live versions with >=. And nothing stops someone from doing both if they > want. > > > -- > fonts, gcc-porting, it makes no sense how it makes no sense > toolchain, wxwidgets but i'll take it free anytime > @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 If the majority of the devs ( at least of those who participate to this thread ) is positive, then I will commit a patch to devmanual and possibly migrate the cvs&svn sources pages into a single one. -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org Key ID: 441AC410 Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410 pgpsfTTz5FfRI.pgp Description: PGP signature
Re: [gentoo-dev] Re: Change policy about live ebuilds
On 11/21/10 20:30, Ryan Hill wrote: >> Actually not. Users are already familiar with the - concept so there >> is no point to add extra obstacles in their way. I am trying to find out >> corner cases where double masking makes sense. Otherwise it makes no >> sense to me. Actually the majority of users get confused when a package >> is double masked. Just drop by forums etc and you will see :) > > Again, that's the point. If you can't figure out how to get around a > double mask then you have no business installing live ebuilds. I know how to do it and still am grateful if I don't have to do both of them. It's not about users only. > If you want to change the policy to recommend > dropping keywords rather than using package.mask then I support it. +1 for KEYWORDS="". Less effort, less likely to break the tree. Sebastian
Re: [gentoo-dev] Re: Change policy about live ebuilds
On 11/21/10 17:27, Markos Chandras wrote: >> Where can I find the rest of this thread? > Ehh, maybe on gentoo archives? > http://archives.gentoo.org/gentoo-dev/msg_4934999b1188cf3ecc53fea784054afb.xml > > Is that what you are asking for? In a way, yes, thanks. Should have thought of looking there. I supposed that you guys were talking somewhere else before: Your mail starting the thread never got here. Your later mail that Ryan replied to never got here either. So I guess maybe my spam detection has a problem. Best Sebastian
[gentoo-dev] Re: Change policy about live ebuilds
On Sun, 21 Nov 2010 13:11:53 + Markos Chandras wrote: > Users interpret this as a 'double masking' which in fact it is since > they need to touch two files before they are able to use the package. Isn't that the point? People should be discouraged in every way not to use live ebuilds. I'd add a third if we had one. :) But yes, if I had to pick only one I'd go with dropping keywords over package.mask. In fact it looks like I have some live ebuilds in the tree that do exactly that. -- fonts, gcc-porting, it makes no sense how it makes no sense toolchain, wxwidgets but i'll take it free anytime @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: GCC 4.5 unmasking tomorrow
On Saturday, November 20, 2010 21:57:21 Ryan Hill wrote: > On Sun, 21 Nov 2010 01:38:23 +0200 Nikos Chantziaras wrote: > > On 11/21/2010 12:46 AM, Ryan Hill wrote: > > > I'm unmasking sys-devel/gcc-4.5.1 tomorrow. I'd like to recommend > > > everyone who has already unmasked it to rebuild it now as there has > > > been some important patches added recently (see ChangeLog). > > > > revbump? > > We don't do revbumps on masked toolchain packages. well, not quite. the way we agreed in the past was to not revbump the masked package, but once it was unmasked, we revbump it just once at that point. -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: GCC 4.5 unmasking tomorrow
On Sun, 21 Nov 2010 17:59:25 +0100 Michał Górny wrote: > > Users unmasking toolchain packages need to be paying close attention > > to what's going on behind the scenes. They're in the tree for people > > who know what they're doing to test. Even unmasked, toolchain > > revbumps are expensive and we do them only when absolutely necessary. > > I think users would appreciate it if you mentioned that in the mask > message. Just for the future. > # Mark Loeser (24 Apr 2010) # Masked for testing. Only use this version of gcc if you know what you are # doing =sys-devel/gcc-4.5* -- fonts, gcc-porting, it makes no sense how it makes no sense toolchain, wxwidgets but i'll take it free anytime @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Change policy about live ebuilds
On Sun, Nov 21, 2010 at 01:00:03PM -0600, Ryan Hill wrote: > On Sun, 21 Nov 2010 13:11:53 + > Markos Chandras wrote: > > > Users interpret this as a 'double masking' which in fact it is since > > they need to touch two files before they are able to use the package. > > Isn't that the point? People should be discouraged in every way not to use > live ebuilds. I'd add a third if we had one. :) > > But yes, if I had to pick only one I'd go with dropping keywords over > package.mask. In fact it looks like I have some live ebuilds in the tree > that do exactly that. > Actually not. Users are already familiar with the - concept so there is no point to add extra obstacles in their way. I am trying to find out corner cases where double masking makes sense. Otherwise it makes no sense to me. Actually the majority of users get confused when a package is double masked. Just drop by forums etc and you will see :) -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org Key ID: 441AC410 Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410 pgppderna1BFI.pgp Description: PGP signature
[gentoo-dev] Re: GCC 4.5 unmasking tomorrow
On 11/21/2010 08:49 PM, Ryan Hill wrote: On Sun, 21 Nov 2010 13:54:19 +0200 Alex Alexander wrote: On Sun, Nov 21, 2010 at 01:47:57AM -0600, Ryan Hill wrote: On Sun, 21 Nov 2010 17:35:18 +1300 Alistair Bush wrote: We don't do revbumps on masked toolchain packages. Why not? Yeah why not? do you inform users of this? Users unmasking toolchain packages need to be paying close attention to what's going on behind the scenes. They're in the tree for people who know what they're doing to test. Even unmasked, toolchain revbumps are expensive and we do them only when absolutely necessary. If you pushed important fixes to gcc, you should revbump it before unmasking it. If you skip the revbump, I'm sure most users will miss this. There's virtually no expense to a revbump in this case. You just asked every user currently using gcc-4.5.1 to rebuild it, isn't a revbump the best, safest way to do that? Since everyone and their dog seems to have unmasked it already I'll make an exception. :-P I don't know about the others, but I unmasked it in order to test it against non-portage compiles. Just because people unmask it doesn't necessarily mean they switched their system gcc profile to it. The problem should be obvious; those people will then see that it got unmasked, so will assume it's ready for testing in-tree packages with it and switch their gcc profile. But without a revbump...
[gentoo-dev] Re: GCC 4.5 unmasking tomorrow
On Sun, 21 Nov 2010 13:54:19 +0200 Alex Alexander wrote: > On Sun, Nov 21, 2010 at 01:47:57AM -0600, Ryan Hill wrote: > > On Sun, 21 Nov 2010 17:35:18 +1300 > > Alistair Bush wrote: > > > > > > > We don't do revbumps on masked toolchain packages. > > > > > > > > Why not? > > > > > > Yeah why not? do you inform users of this? > > > > Users unmasking toolchain packages need to be paying close attention to > > what's going on behind the scenes. They're in the tree for people who > > know what they're doing to test. Even unmasked, toolchain revbumps are > > expensive and we do them only when absolutely necessary. > > If you pushed important fixes to gcc, you should revbump it before > unmasking it. > > If you skip the revbump, I'm sure most users will miss this. > > There's virtually no expense to a revbump in this case. You just asked > every user currently using gcc-4.5.1 to rebuild it, isn't a revbump the > best, safest way to do that? Since everyone and their dog seems to have unmasked it already I'll make an exception. -- fonts, gcc-porting, it makes no sense how it makes no sense toolchain, wxwidgets but i'll take it free anytime @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Change policy about live ebuilds
On Sun, Nov 21, 2010 at 04:22:52PM +0100, Sebastian Pipping wrote: > Diego, > > > On 11/21/10 15:29, Diego Elio Pettenò wrote: > > The reason why many of them are in p.mask is usually because _I_ added > > them there as they didn't mask with KEYWORDS="", and simply dropping > > keywords would have users angry. > > Why does KEYWORDS="" on live ebuilds make users angry? > > Where can I find the rest of this thread? Ehh, maybe on gentoo archives? http://archives.gentoo.org/gentoo-dev/msg_4934999b1188cf3ecc53fea784054afb.xml Is that what you are asking for? > > Where can I find documentation of the _current_ policy? > Here http://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/cvs-sources/index.html http://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/svn-sources/index.html > Thanks! > > > > Sebastian > -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org Key ID: 441AC410 Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410 pgpbUdAWrVhuY.pgp Description: PGP signature
Re: [gentoo-dev] Re: GCC 4.5 unmasking tomorrow
On 11/21/10 08:47, Ryan Hill wrote: > toolchain revbumps are expensive How expansive? More than a rebuild of GCC itself? Best, Sebastian
Re: [gentoo-dev] Re: GCC 4.5 unmasking tomorrow
On Sun, 21 Nov 2010 01:47:57 -0600 Ryan Hill wrote: > On Sun, 21 Nov 2010 17:35:18 +1300 > Alistair Bush wrote: > > > > > We don't do revbumps on masked toolchain packages. > > > > > > Why not? > > > > Yeah why not? do you inform users of this? > > Users unmasking toolchain packages need to be paying close attention > to what's going on behind the scenes. They're in the tree for people > who know what they're doing to test. Even unmasked, toolchain > revbumps are expensive and we do them only when absolutely necessary. I think users would appreciate it if you mentioned that in the mask message. Just for the future. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Change policy about live ebuilds
Diego, On 11/21/10 15:29, Diego Elio Pettenò wrote: > The reason why many of them are in p.mask is usually because _I_ added > them there as they didn't mask with KEYWORDS="", and simply dropping > keywords would have users angry. Why does KEYWORDS="" on live ebuilds make users angry? Where can I find the rest of this thread? Where can I find documentation of the _current_ policy? Thanks! Sebastian
Re: [gentoo-dev] Re: Change policy about live ebuilds
On Sun, Nov 21, 2010 at 03:29:10PM +0100, Diego Elio Pettenò wrote: > Il giorno dom, 21/11/2010 alle 13.11 +, Markos Chandras ha scritto: > > > > My proposal is to keep empty keywords on live ebuilds without masking > > them via package.mask > > The reason why many of them are in p.mask is usually because _I_ added > them there as they didn't mask with KEYWORDS="", and simply dropping > keywords would have users angry. This is the alternative approach. Retain the keywords and mask the package which doesn't look that safe in case you have both a normal version and a live ebuild masked. Then users should pay extra attention which version they unmask. > > > > Users interpret this as a 'double masking' which in fact it is since > > they need to touch two files before they are able to use the package. > > Fine by me, but the problem remains that users won't know _why_ the > package is masked, way too many times. I don't understand that. The default policy would be empty keywords. If you need to mask a live ebuild using package.mask because e.g master branch is terribly broken or whatever then it makes sense. But I am not sure I understand what you are saying :-) > > -- > Diego Elio Pettenò — “Flameeyes” > http://blog.flameeyes.eu/ > > If you found a .asc file in this mail and know not what it is, > it's a GnuPG digital signature: http://www.gnupg.org/ > > -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org Key ID: 441AC410 Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410 pgpeCubfRreEw.pgp Description: PGP signature
[gentoo-dev] Re: Change policy about live ebuilds
Il giorno dom, 21/11/2010 alle 13.11 +, Markos Chandras ha scritto: > > My proposal is to keep empty keywords on live ebuilds without masking > them via package.mask The reason why many of them are in p.mask is usually because _I_ added them there as they didn't mask with KEYWORDS="", and simply dropping keywords would have users angry. > > Users interpret this as a 'double masking' which in fact it is since > they need to touch two files before they are able to use the package. Fine by me, but the problem remains that users won't know _why_ the package is masked, way too many times. -- Diego Elio Pettenò — “Flameeyes” http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/
Re: [gentoo-dev] Change policy about live ebuilds
On Sun, Nov 21, 2010 at 01:11:53PM +, Markos Chandras wrote:
> Hi there,
>
> The official policy for live ebuilds is the following one:
>
> http://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/cvs-sources/index.html
>
> I don't quite agree with this policy and I guess most of you don't agree
> either looking at the number of live ebuilds/package.mask entries.
>
> My proposal is to keep empty keywords on live ebuilds without masking
> them via package.mask
>
> Users interpret this as a 'double masking' which in fact it is since
> they need to touch two files before they are able to use the package.
I agree. Forcing the users to add ${P} ** in their keywords is enough,
it states that "they're on their own".
> I also know that we can use overlays for that, but distribute the
> ebuilds among dev/proj overlays is not always a solution.
+1
for big projects like KDE, overlays are a better place, but for small
packages, they are overkill.
--
Alex Alexander | wired
+ Gentoo Linux Developer
++ www.linuxized.com
pgprpo8XtIFmz.pgp
Description: PGP signature
[gentoo-dev] Change policy about live ebuilds
Hi there, The official policy for live ebuilds is the following one: http://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/cvs-sources/index.html I don't quite agree with this policy and I guess most of you don't agree either looking at the number of live ebuilds/package.mask entries. My proposal is to keep empty keywords on live ebuilds without masking them via package.mask Users interpret this as a 'double masking' which in fact it is since they need to touch two files before they are able to use the package. I also know that we can use overlays for that, but distribute the ebuilds among dev/proj overlays is not always a solution. -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org Key ID: 441AC410 Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410 pgpJ98thx416D.pgp Description: PGP signature
Re: [gentoo-dev] Re: GCC 4.5 unmasking tomorrow
В Вск, 21/11/2010 в 01:47 -0600, Ryan Hill пишет: > On Sun, 21 Nov 2010 17:35:18 +1300 > Alistair Bush wrote: > > > > > We don't do revbumps on masked toolchain packages. > > > > > > Why not? > > > > Yeah why not? do you inform users of this? > > Users unmasking toolchain packages need to be paying close attention to > what's going on behind the scenes. They're in the tree for people who > know what they're doing to test. Even unmasked, toolchain revbumps are > expensive and we do them only when absolutely necessary. I don't see any reasons not to revbump package even if it was hardmasked... -- Peter.
Re: [gentoo-dev] IUSE="minimal" seems like a bad idea
On Sat, 20 Nov 2010 23:44:05 -0500 Matt Turner wrote: > matts...@sempron /usr/portage $ egrep -l 'IUSE=.*minimal' `find -name > '*.ebuild'` > > ^ shows lots of ebuilds with IUSE="minimal". Instead of having a > minimal use flag for these packages, shouldn't we have, possibly > local, use flags for whatever feature(s) the minimal flag turns off? For vim, which is where I believe the minimal flag originated, you'd have to have twenty or thirty individual flags for the vim features in question, and many of them are interdependent. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: GCC 4.5 unmasking tomorrow
On Sun, Nov 21, 2010 at 01:47:57AM -0600, Ryan Hill wrote: > On Sun, 21 Nov 2010 17:35:18 +1300 > Alistair Bush wrote: > > > > > We don't do revbumps on masked toolchain packages. > > > > > > Why not? > > > > Yeah why not? do you inform users of this? > > Users unmasking toolchain packages need to be paying close attention to > what's going on behind the scenes. They're in the tree for people who > know what they're doing to test. Even unmasked, toolchain revbumps are > expensive and we do them only when absolutely necessary. If you pushed important fixes to gcc, you should revbump it before unmasking it. If you skip the revbump, I'm sure most users will miss this. There's virtually no expense to a revbump in this case. You just asked every user currently using gcc-4.5.1 to rebuild it, isn't a revbump the best, safest way to do that? -- Alex Alexander | wired + Gentoo Linux Developer ++ www.linuxized.com pgppwbotqb0dQ.pgp Description: PGP signature
Re: [gentoo-dev] IUSE="minimal" seems like a bad idea
On Sat, 20 Nov 2010 23:44:05 -0500 Matt Turner wrote: > matts...@sempron /usr/portage $ egrep -l 'IUSE=.*minimal' `find -name > '*.ebuild'` > > ^ shows lots of ebuilds with IUSE="minimal". Instead of having a > minimal use flag for these packages, shouldn't we have, possibly > local, use flags for whatever feature(s) the minimal flag turns off? I used 'minimal' disable a set of additional features (metadata.xml-clarified) not having extensive use but raising the binary size. I think that's better than having 5 other flags doing almost nothing (and having to be declared as +flag by default). -- Best regards, Michał Górny signature.asc Description: PGP signature
