Re: [gentoo-dev] Re: [gentoo-core] gtk/gtk2 USE flag annoyances
On Fri, Sep 02, 2005 at 07:58:05AM +0200, Marius Mauch wrote: On 08/26/05 Brian Harring wrote: On Fri, Aug 26, 2005 at 11:44:44AM -0400, Dan Meltzer wrote: Hows the upgrade path RE: end-user useflag changes? Will everyone that has gtk in their make.conf die a horrible death if they don't see the upgrade notice? when will they see the upgrade notice? Would it make sense to leave the gtk flag for a while at least, to ease the end user into an upgrade? Not saying it's a clean idea, but aside from making a lot of noise about the change over (which should be delayed till that noise has been made), a base/profile.bashrc trick of substituting gtk in when gtk1 is detected would work. Hell no. Don't need to add more confusion to the use flag confusion. Instead, confuse the hell out of users who don't religiously follow -dev/-user/-gwn, and suddenly get bit by the gtk flag losing it's meaning? That said, it won't work anyways; the aliasing has to occur within the python side else it'll screw up the depgraph (realized that just a few seconds ago) :) So... back to making a lot of noise, or some python side support for aliasing use flags. ~harring pgpfNB2mFzyUY.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] EAPI
On 08/26/05 Kristian Benoit wrote: On the EAPI subject Brian just brought back, I had this idea that we could use the same approch XML took with HTML. The ebuild could define which EAPI to use, but instead beiing a version, the EAPI would be an ebuild API definition. The equivalent to the XML's dtd. The ebuild could point to a directory named $PORTDIR/eapi/eapi-name/ which would contain a python script named eapi-name.py. If not already loaded, that plugable eapi would be loaded before processing the ebuild. That way, there is no outdated ebuild format. There is just a default format which is the actual format. It could also be an XML defining the ebuild's build sequence and other particularities a group of ebuild could have. As EAPI is closely tied to portage internals (DEPEND handling for example) that's not really going to work from within the tree. Otherwise we could just distribute portage completely with the tree, no? Don't mind having it pluggable inside portage, but as it can potentially affect many areas I doubt that's realistic. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir
On 08/27/05 Brian Harring wrote: Hola all. Straight to the point, I'm proposing that the following files- arch.list categories use.desc use.local.desc package.mask updates be moved out of the profiles directory in the tree, and into the existing metadata directory personally, due to the fact that the files above are essentially repository metadata. Why move them *now* when they've been around forever? [snip] Don't mind moving them, BUT - metadata is a stupid location for them for several reasons - don't really like adding more cruft to the regen script - why move them now and then move/redesgin them again when someone finally makes a sane profiles design (yeah, I've talked about that for months now :-/) Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir
On Fri, Sep 02, 2005 at 08:17:39AM +0200, Marius Mauch wrote: On 08/27/05 Brian Harring wrote: Straight to the point, I'm proposing that the following files- arch.list categories use.desc use.local.desc package.mask updates be moved out of the profiles directory in the tree, and into the existing metadata directory personally, due to the fact that the files above are essentially repository metadata. Why move them *now* when they've been around forever? [snip] Don't mind moving them, BUT - metadata is a stupid location for them for several reasons being? metadata already holds global repository information, time of repositories generation, pregenerated cache, glsa set... It holds global metadata for the repository. - don't really like adding more cruft to the regen script Agreed. That said, users bitching when the don't upgrade their tools, and said tools start breaking isn't fun. - why move them now and then move/redesgin them again when someone finally makes a sane profiles design (yeah, I've talked about that for months now :-/) Anyone after redesigning profiles has their hands full. Do this change now, profile redesign isn't burdened with dealing with this mess. This change over as indicated in other postings to this thread also would prepare for allowing full capabilities to standalone repositories, rather then coming up with a hack that pulls the data from profiles. The change over can be done pretty cleanly, and organizes stuff as it should be, in preparation of upcoming tweaks/capabilities/whatever. I'd rather nip this now, rather then when it starts creating problems down the line. ~harring pgpMOXARvsGs3.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-core] gtk/gtk2 USE flag annoyances
On 08/29/05 Brian Harring wrote: That said, it won't work anyways; the aliasing has to occur within the python side else it'll screw up the depgraph (realized that just a few seconds ago) :) So... back to making a lot of noise, or some python side support for aliasing use flags. ~harring Adding Global Update support similar to package moves? Has the benefit of people becoming aware of the change. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir
On 08/29/05 Brian Harring wrote: On Fri, Sep 02, 2005 at 08:17:39AM +0200, Marius Mauch wrote: Don't mind moving them, BUT - metadata is a stupid location for them for several reasons being? metadata already holds global repository information, time of repositories generation, pregenerated cache, glsa set... It holds global metadata for the repository. a) doesn't exist in CVS b) is generally associated with populated by cvs-rsync c) becomes just another dumping ground (it should only hold the cache IMO) d) This isn't metadata at all Name it misc or global or some other non-existing-dir. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Fixing the TERM mess
Ciaran McCreesh wrote:
On Sun, 21 Aug 2005 18:43:54 -0400 Dan Meltzer
[EMAIL PROTECTED] wrote:
| putty pretends to be an xterm and dies at xtermcontrol --get-bg... I
| can test other things if you need.. just give me some idea :)
Thanks. The other useful one is to see whether it does 256 colours
properly like real xterm does. The following bash script, when run with
'256' as its argument, should look the same as it does when run under
a real xterm.
#!/usr/bin/env bash
# vim: set sw=4 sts=4 et :
[[ -z ${1} ]] cat END exit 1
Usage: ${0} [count]
count should usually be either 88 (rxvt-based terminals) or 256
(xterm-based terminals).
END
echo -n 0:
for (( a = 0 ; a ${1} ; a++ )) ; do
echo -n -e \e[38;5;${a#0}m#\e[48;5;${a#0}mX\e[0;0m
[[ -z ${a##*9} ]] echo -n -e \n\e[0;0m$(printf '%3d' ${a} ):
done
echo -e \e[0;0m ; echo
Probably putty use xterm as default instead to be usable on most
configurations.
I've found that putty is the best (free on windows) linux term
emulator around.
As a consequence all my win boxes use it with the following settings:
Terminal - Keyboard - The Functions keys and keypad - Linux
Connection - Data - Terminal-type string - linux
with this settings the xtermcontrol --get-bg output this:
xtermcontrol: TERM=linux: probably not xterm variant
The script you posted here has good results for $1 = 256 for putty
version 0.58 .
For version 0.56 of putty the for loop need to start from 13 instead
of 0 or it screwed up things at the extend that a reset need to be
run. Additionally the color support is limited to 16 .
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gstreamer + Use Flags
On Tue, 23 Aug 2005 02:33:53 -0500, Brian Harring wrote As stated in 100872, any solution involving centralizing the use flags on gstreamer requires use deps. Can't centralize the use flags on gstreamer till they're available, without doing something QA has every right to wedgie you for (build_with_use die's in pkg_setup). Not at all. As you see in the answer from Carsten Lohrke on 100872 centralizing use flags has nothing to do with use deps in this case (gstreamer). The point is that as soon as a plugin is available to one application it's available to all - despite of having the corresponding use flagged dependency set or not. That's a) illogical and b) when users uninstall a plugin they did not depend on for one application, but are used to it in between because it was invoked by another ebuild, you run into exactly the same problem (and possible bug reports): Users who don't know how their applications with gstreamer work. fabian -- ... I want something good to die for To make it beautiful to live. I want a new mistake, lose is more than hesitate. Do you believe it in your head? - Queens of the Stone Age - Go with the Flow I prefer signed/encrypted Mail (even if I can't write it myself at the moment due to OpenWebMail deficiencies): Fingerprint: CFE8 38A7 0BC4 3CB0 E454 FA8D 04F9 B3B6 E02D 25BA -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Fixing the TERM mess
On Mon, 29 Aug 2005 09:28:28 +0200 ivan vadovič [EMAIL PROTECTED] wrote: | I think the key thing here is that the application should be able to | ask the terminal for its feature set. Should and can are two entirely different things. We're dealing with reality here and trying to cope with fifty years or so of differing terminal designs. | That'd also solve the cases where a terminal changes right beneath a | running application. That | happens during attaching a screen session. No it doesn't. Screen provides a virtual terminal with lots and lots of capabilities. It then reduces them itself internally to what it thinks the underlying term supports -- again, this is done via terminfo, so if you're running screen on xterm you're running a crippled screen. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpkremiphy1t.pgp Description: PGP signature
Re: [gentoo-dev] crap use flags in the profiles
On Thu, 2005-08-25 at 00:28 -0400, Mike Frysinger wrote:
- base doesnt define any USE
- default-linux defines a few local xorg USE (because no one has given us the
ability to control default USE via IUSE yet :P)
{x86,amd64}/make.defaults has the 'bloated' USE because every single sub x86
and amd64 profile had the same USE in them ... if you want to re-push them
into subprofiles like 200[45].[01], that's fine by me ... will have to check
with wolf/releng so they dont revert it :P
I moved them from the sub-profiles since they were redundant.
As for the profiles... the versioned profiles that you see are the ones
used by releng for each architecture to build the release. This means
they have all of the USE flags that we want enabled for the release.
While we could create a smaller set of USE flags for the x86 (and
amd64) profiles, then only add the huge USE list to the versioned
profiles, it wouldn't make a bit of difference, since everything we have
everywhere points the users to the versioned profiles anyway.
Basically, it would add more work for whomever maintains the profiles,
and our users wouldn't gain anything from it. Currently, there is
nothing stopping anyone from creating a server sub-profile that only
had a minimal set of USE flags. The reason why there isn't any is
because nobody is taking the time and energy to do it. Basically, the
capability is there, but with nobody actually doing it, it tells me that
the demand isn't there.
The other thing is that any profile that shows up in the tree under
default-linux ends up being releng's responsibility, for the most part.
Can't users define their own profiles? Why do we need to make one
ourselves? Our profiles are defaults, not meant to be the end-all
be-all of USE flag selection.
We've actually been talking about making the profiles more like this,
but really need to weigh the additional work required to validate them
before we go deciding that we're going to start adding profiles for
specific uses. I tend to believe that if we start adding them, we'll
soon be bombarded with I want a $x profile because I don't like this
one USE flag kind of bugs. It's much easier to say this is our
defaults, change them as you like than it is to provide multiple sets
of defaults all of which are completely arbitrary.
It would also increase the amount of work that needs to be done when the
defaults do need to be changed.
--
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
On Wed, 2005-08-24 at 21:30 -0500, Kito wrote: So yeah, subprofiles, reasons why not? Aside from the work involved, I see no reason to not use the cascades for what they seem to be made for. As I understood it, they were implemented to reduce the amount of work necessary in maintaining them. As it was back then, it required changes to an extremely large number of profiles every time a change was made to the default USE flags. I honestly don't think it would be a good idea to forget the lessons of the past and start bloating the profiles with tons of desktop and server profiles, among anything else people would want. After all, as soon as we did a desktop profile, then we would have requests for gnome and kde sub-profiles. As I stated earlier, it's easier to not provide *any* than to try to provide all of the ones that will inevitably be requested as soon as we start adding them. -- Chris Gianelloni Release Engineering - Strategic Lead/QA Manager Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] crap use flags in the profiles
Chris Gianelloni wrote:
On Thu, 2005-08-25 at 00:28 -0400, Mike Frysinger wrote:
- base doesnt define any USE
- default-linux defines a few local xorg USE (because no one has given us the
ability to control default USE via IUSE yet :P)
{x86,amd64}/make.defaults has the 'bloated' USE because every single sub x86
and amd64 profile had the same USE in them ... if you want to re-push them
into subprofiles like 200[45].[01], that's fine by me ... will have to check
with wolf/releng so they dont revert it :P
We've actually been talking about making the profiles more like this,
but really need to weigh the additional work required to validate them
before we go deciding that we're going to start adding profiles for
specific uses. I tend to believe that if we start adding them, we'll
soon be bombarded with I want a $x profile because I don't like this
one USE flag kind of bugs. It's much easier to say this is our
defaults, change them as you like than it is to provide multiple sets
of defaults all of which are completely arbitrary.
That's for sure that will happen. I also agree with keeping a default
and letting the users build their own profiles out of it.
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
Chris Gianelloni wrote: On Wed, 2005-08-24 at 21:30 -0500, Kito wrote: So yeah, subprofiles, reasons why not? Aside from the work involved, I see no reason to not use the cascades for what they seem to be made for. As I understood it, they were implemented to reduce the amount of work necessary in maintaining them. As it was back then, it required changes to an extremely large number of profiles every time a change was made to the default USE flags. I honestly don't think it would be a good idea to forget the lessons of the past and start bloating the profiles with tons of desktop and server profiles, among anything else people would want. After all, as soon as we did a desktop profile, then we would have requests for gnome and kde sub-profiles. As I stated earlier, it's easier to not provide *any* than to try to provide all of the ones that will inevitably be requested as soon as we start adding them. In general, it sounds like a good idea, but as far as i can see, it would be a for-the-user and by-the-user idea, but what about for the devs, it doesn't look like something easy to mantain. Nevertheless, what if we can provide instead tools/docs to help users with the task?, so anyone willing to do it, could easily create his/her own sub-profiles for kde/gnome/whatever ... Just an idea :-] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
On Sat, 2005-08-27 at 05:01 -0500, Brian Harring wrote: What I'm advocating is that the '05 profile (fex) tag in the defaults for that profile release, desktop/server agnostic, *system* defaults, eg toolchain, pam, nptl, etc. The subprofile the user chooses (the desktop or server target) building upon those base settngs. Multiple inherits for profiles is the main reason I'm not pushing on this; shifting desktop cruft out of the bases (my definition of base mind you) requires pulling from (fex) x86/2005.1 + desktop/2005.1 . Currently, the versioned profiles match what we use for building the release. The 2005.1 profile is the USE flags used to build the 2005.1 release. This makes complete sense to me and is the way it has been done in the past. Making the changes that you propose would require a 2005.1/desktop profile to be used for building GRP. The problem with this is it would also require that the same profile be used for building the stages. Basically, you've taken then 2005.1 profile and made it useless, since the stages weren't built against it anyway. My point is pretty simple, why should we spend a bunch of time maintaining something that is designed from the start to be customized, and most likely won't even be used anyway? I would much rather stick with the 2005.1 profile meaning what we used to build 2005.1 than having it mean some variation of 2005.1 is below here and using this profile is minimal and likely won't do what you expect. -- Chris Gianelloni Release Engineering - Strategic Lead/QA Manager Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] why does gcc-3.4.x depend on gcc-3.3.x / libstdc++?
On Sat, 2005-08-27 at 02:46 +0200, Bjarke Istrup Pedersen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I must say I have been wondering about this for a while too. A solution might be add some sort of flag to packages that are binary, and then let portage install libstdc++ the first time you install this kind of package. You're right. We could even make it a dependency based on the gcc version. Wouldn't that be neat? Maybe something like this: || ( =gcc-3.3* libstdc++-v3 ) For the humor impaired, this was a joke. Why is it a joke? Because you're missing the non-binary packages that this completely breaks. Want a cool, small example? Install gcc 3.3, configure it as your primary compiler, emerge fluxbox, upgrade to gcc 3.4 and remove all traces of gcc 3.3 and libstdc++-v3, then try running fluxbox. Basically, vapier got tired of all of the my $foo package is broken bugs because people didn't realize that anything that linked against the older gcc would *require* being recompiled to work properly. The solution? Add this library by default. -- Chris Gianelloni Release Engineering - Strategic Lead/QA Manager Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir
On Sat, 2005-08-27 at 03:42 -0500, Brian Harring wrote: Further, while no one has yet proposed anything concrete, people have been after revamping the profile implementation. Quite likely if/when this occurs, it's going to require a seperate directory to avoid any issues with older portage installations accessing it. Shifting the files now while changes are being made addresses that concern, and makes things a bit more logical. This could still be done under profiles. Personally, I like the idea of something more like this: project/os/arch/version for profiles This would give us something like this: default/linux/x86/2006.0 default/freebsd/alpha/2006.0 hardened/linux/amd64/2006.0/2.4 hardened/freebsd/x86/2006.0 uclibc/linux/mips/2006.0/cobalt server/linux/x86/2006.0 etc. Two scenarios for how this will result in visible issues for people- 1) CVS users, aka, devs. Devs *should* be running latest portage, which would know about the shift. If they're running an older portage version and aren't willing to upgrade, they tag the symlinks themselves. It's a minor annoyance frankly; assuming they read -dev (like they're suppossed to :P ), they'll know in advance it's coming. Many devs use the latest stable versions of packages rather than testing versions. I tend to find this to be a good thing as there are often bugs in particular combinations of package versions that aren't necessarily spotted when running all ~arch. Also, devs are not required to read or even be subscribed to -dev. -- Chris Gianelloni Release Engineering - Strategic Lead/QA Manager Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
On Mon, 2005-08-29 at 11:59 -0400, Chris Gianelloni wrote: As I understood it, they were implemented to reduce the amount of work necessary in maintaining them. As it was back then, it required changes to an extremely large number of profiles every time a change was made to the default USE flags. Just a crazy idea - why not create a package containing some profiles? You can use the default profile, and if you want a different profile, emerge portage-profiles or whatever it is called and use that. I guess I've missed something obvious here? I honestly don't think it would be a good idea to forget the lessons of the past and start bloating the profiles with tons of desktop and server profiles, among anything else people would want. After all, as soon as we did a desktop profile, then we would have requests for gnome and kde sub-profiles. which are not much work if kde = desktop -gtk -gnome +kde As I stated earlier, it's easier to not provide *any* than to try to provide all of the ones that will inevitably be requested as soon as we start adding them. Or provide them in an extra ebuild that throws lots of warnings so that any users that don't read the warnings can be RESOLVED WONTFIXed? -- Stand still, and let the rest of the universe move signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
If it was an extra ebuild, the profiles directory would need to exist outside of /usr/portage, would it not? This to prevent it from being blown up at next sync. On 8/29/05, Patrick Lauer [EMAIL PROTECTED] wrote: On Mon, 2005-08-29 at 11:59 -0400, Chris Gianelloni wrote: As I understood it, they were implemented to reduce the amount of work necessary in maintaining them. As it was back then, it required changes to an extremely large number of profiles every time a change was made to the default USE flags. Just a crazy idea - why not create a package containing some profiles? You can use the default profile, and if you want a different profile, emerge portage-profiles or whatever it is called and use that. I guess I've missed something obvious here? I honestly don't think it would be a good idea to forget the lessons of the past and start bloating the profiles with tons of desktop and server profiles, among anything else people would want. After all, as soon as we did a desktop profile, then we would have requests for gnome and kde sub-profiles. which are not much work if kde = desktop -gtk -gnome +kde As I stated earlier, it's easier to not provide *any* than to try to provide all of the ones that will inevitably be requested as soon as we start adding them. Or provide them in an extra ebuild that throws lots of warnings so that any users that don't read the warnings can be RESOLVED WONTFIXed? -- Stand still, and let the rest of the universe move -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2-ecc0.1.6 (GNU/Linux) iD8DBQBDE0+EqER3hOUoZM4RAoExAJ9vJH9lSOug5o8gVYljtNewLucYnwCcCgL5 uBwy5L+fKeOF2nw/YzyfjSM= =WwNl -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
On Mon, 2005-08-29 at 20:10 +0200, Patrick Lauer wrote: On Mon, 2005-08-29 at 11:59 -0400, Chris Gianelloni wrote: As I understood it, they were implemented to reduce the amount of work necessary in maintaining them. As it was back then, it required changes to an extremely large number of profiles every time a change was made to the default USE flags. Just a crazy idea - why not create a package containing some profiles? You can use the default profile, and if you want a different profile, emerge portage-profiles or whatever it is called and use that. I guess I've missed something obvious here? How exactly would updating a ton of profiles, making a tarball of them, uploading the new tarball, waiting for it to hit the mirrors, then updating the ebuild in portage be easier to maintain than just maintaining the profiles directly in the tree? I honestly don't think it would be a good idea to forget the lessons of the past and start bloating the profiles with tons of desktop and server profiles, among anything else people would want. After all, as soon as we did a desktop profile, then we would have requests for gnome and kde sub-profiles. which are not much work if kde = desktop -gtk -gnome +kde Once there is multiple inheritance, I see this being easier. I still think it is going to be a waste of time for us to maintain them, however. Especially since *NO MEDIA* will be built against *any* of them except the default. As I stated earlier, it's easier to not provide *any* than to try to provide all of the ones that will inevitably be requested as soon as we start adding them. Or provide them in an extra ebuild that throws lots of warnings so that any users that don't read the warnings can be RESOLVED WONTFIXed? You're more than welcome to do this. *I* would just WONTFIX it anyway and not add *any* superfluous profiles just to appease some lazy users. The current profiles are built to be used *as is* for doing GRP installations. If the user doesn't like a flag or two, then they change it themselves. We don't need to get into the business of determining what should and should not be enabled on user's systems because we would *never* be able to make people happy. -- Chris Gianelloni Release Engineering - Strategic Lead/QA Manager Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
On Mon, Aug 29, 2005 at 12:56:35PM -0400, Chris Gianelloni wrote: On Sat, 2005-08-27 at 05:01 -0500, Brian Harring wrote: Basically, you've taken then 2005.1 profile and made it useless, since the stages weren't built against it anyway. Via that logic (don't change it lest it negates a release), we would never be able to do changes, or would be forced to do changes strictly whenever y'all are doing a new release. Profiles aren't bound to the releases, despite how people may view it and/or the current profile maitnainer's usage of 'em. My point is pretty simple, why should we spend a bunch of time maintaining something that is designed from the start to be customized, and most likely won't even be used anyway? That's the issue; the profiles in their current form are customizable only in the ability to negate a collection of flags. Negating the whole beast is another story due to the desktop cruft being shoved into the arch subprofiles. I would much rather stick with the 2005.1 profile meaning what we used to build 2005.1 than having it mean some variation of 2005.1 is below here and using this profile is minimal and likely won't do what you expect. Again, releases may be bound by available profiles, but available profiles are not bound by available releases. Aside from that, the comments about variations/minimal/not doing what you expect, what do you think USE=-* user's actual desired flags accomplishes? Profile customization occurs, /etc/portage/profiles exists for this reason; the 2005.1 profile (fex) is probably *rarely* ran exactly as y'all have it specified considering we do have user level use flags, tweaking the hell out of '05.1. Aside from mild disagreement on views, as was stated in previous emails, multiple inheritance I tend to think is required to minimize the work for y'all; what I want you guys to do (or I'll do myself) is chunk the suckers up so people after a minimal base for running it themselves, or building up their own subprofile can do so. Not after jamming maintenance nightmares on you, which without multiple inheritance, might be a bit. ~harring pgpnO9KjjXNG9.pgp Description: PGP signature
Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir
On Mon, Aug 29, 2005 at 01:27:34PM -0400, Chris Gianelloni wrote: This could still be done under profiles. Personally, I like the idea of something more like this: project/os/arch/version for profiles This would give us something like this: default/linux/x86/2006.0 default/freebsd/alpha/2006.0 hardened/linux/amd64/2006.0/2.4 hardened/freebsd/x86/2006.0 uclibc/linux/mips/2006.0/cobalt server/linux/x86/2006.0 I like... That's pretty much what I'm aiming for; not after forcing *you* to do server/etc, just would prefer to see it structured so that others can do so. That said, initial email was worded a bit strongly, so pardon ;) Two scenarios for how this will result in visible issues for people- 1) CVS users, aka, devs. Devs *should* be running latest portage, which would know about the shift. If they're running an older portage version and aren't willing to upgrade, they tag the symlinks themselves. It's a minor annoyance frankly; assuming they read -dev (like they're suppossed to :P ), they'll know in advance it's coming. Many devs use the latest stable versions of packages rather than testing versions. I tend to find this to be a good thing as there are often bugs in particular combinations of package versions that aren't necessarily spotted when running all ~arch. Also, devs are not required to read or even be subscribed to -dev. Agreed. Implicit in all this is that I'm going to have to make a bit of noise (and probably attempt and get it shoved out via gwn) prior to doing it, so that I don't have ~100 devs who didn't hear the news looking in my direction. ~harring pgplt9NvIQa2x.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
On Mon, 2005-08-29 at 15:32 -0500, Brian Harring wrote: On Mon, Aug 29, 2005 at 12:56:35PM -0400, Chris Gianelloni wrote: On Sat, 2005-08-27 at 05:01 -0500, Brian Harring wrote: Basically, you've taken then 2005.1 profile and made it useless, since the stages weren't built against it anyway. Via that logic (don't change it lest it negates a release), we would never be able to do changes, or would be forced to do changes strictly whenever y'all are doing a new release. Not exactly. I tend to agree with you that the base arch profiles should be a fairly minimal set of defaults, but also, default-linux has always been tied to releases, as much as possible. The point is that we really should *not* be making changes without media that matches it. Take the recent eds gstreamer thread as a good example. People expect a release to have changes. They don't expect, and don't *want* their system to change underneath them. If I had my way, there wouldn't ever be changes made to any of the profiles, including the arch profiles, unless absolutely necessary, and all changes would go into versioned (or named and versioned, or just named, etc) sub-profiles. The only thing that has kept us from doing this already is the lack of multiple inheritance. Profiles aren't bound to the releases, despite how people may view it and/or the current profile maitnainer's usage of 'em. No, they are not. I never said that they were, either. That being said, it ends up being the release team that ends up getting the bugs for the profiles. While there are a small number of developers that will change profiles under default-linux, it is more often than not left up to each arch's release coordinator. There are also non-release profiles on a few arches. There's nothing stopping you from creating a default-linux/x86/ferringb profile and doing whatever you wish in it, but editing default-linux/x86/2005.1 without speaking with releng would be considered taboo. My point is pretty simple, why should we spend a bunch of time maintaining something that is designed from the start to be customized, and most likely won't even be used anyway? That's the issue; the profiles in their current form are customizable only in the ability to negate a collection of flags. Negating the whole beast is another story due to the desktop cruft being shoved into the arch subprofiles. Sorry, but this didn't make a bit of sense to me. Perhaps you could reword it? I would much rather stick with the 2005.1 profile meaning what we used to build 2005.1 than having it mean some variation of 2005.1 is below here and using this profile is minimal and likely won't do what you expect. Again, releases may be bound by available profiles, but available profiles are not bound by available releases. Nobody ever said that profiles were bound to releases. I said that the versioned profile should match the release it was used to build and nothing more. Please don't insert meaning into what I say. Aside from that, the comments about variations/minimal/not doing what you expect, what do you think USE=-* user's actual desired flags accomplishes? It accomplishes exactly what I think it does. It turns off all automatically-enabled USE flags. I use it personally, because I run with a much smaller set of USE flags and I don't want things being changed without my knowledge. That being said, I also understand that this means I need to spend some time maintaining my systems and checking for the inclusion of new flags when I merge packages or do upgrades. Profile customization occurs, /etc/portage/profiles exists for this reason; the 2005.1 profile (fex) is probably *rarely* ran exactly as y'all have it specified considering we do have user level use flags, tweaking the hell out of '05.1. You would be surprised at the number of people that use GRP and rarely, if ever, change their USE flags. I wish I had numbers, but I don't. Anyway, the default set of USE flags seems to be a pretty perfect mix for most people. It gives packages that work as expected, and is geared toward a desktop system. Without any more specific examples of what you're trying to point out, I'm just not seeing it. Aside from mild disagreement on views, as was stated in previous emails, multiple inheritance I tend to think is required to minimize the work for y'all; what I want you guys to do (or I'll do myself) is chunk the suckers up so people after a minimal base for running it themselves, or building up their own subprofile can do so. Not after jamming maintenance nightmares on you, which without multiple inheritance, might be a bit. I know that I won't be spending *my* time making any profile other than the defaults used for building the release. Anyone is welcome to build profiles for anything else that they might want, but since the release team doesn't use it, we shouldn't be forced to waste our time on it. -- Chris
Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir
On Mon, 2005-08-29 at 15:36 -0500, Brian Harring wrote: On Mon, Aug 29, 2005 at 01:27:34PM -0400, Chris Gianelloni wrote: This could still be done under profiles. Personally, I like the idea of something more like this: project/os/arch/version for profiles This would give us something like this: default/linux/x86/2006.0 default/freebsd/alpha/2006.0 hardened/linux/amd64/2006.0/2.4 hardened/freebsd/x86/2006.0 uclibc/linux/mips/2006.0/cobalt server/linux/x86/2006.0 I like... That's pretty much what I'm aiming for; not after forcing *you* to do server/etc, just would prefer to see it structured so that others can do so. I might just go ahead and do this (at least the default/linux part) for 2006.0, so we can slowly transition away from the default-linux stuff as we deprecate older profiles. That said, initial email was worded a bit strongly, so pardon ;) No problem... it happens when one speaks of something they're passionate about. Two scenarios for how this will result in visible issues for people- 1) CVS users, aka, devs. Devs *should* be running latest portage, which would know about the shift. If they're running an older portage version and aren't willing to upgrade, they tag the symlinks themselves. It's a minor annoyance frankly; assuming they read -dev (like they're suppossed to :P ), they'll know in advance it's coming. Many devs use the latest stable versions of packages rather than testing versions. I tend to find this to be a good thing as there are often bugs in particular combinations of package versions that aren't necessarily spotted when running all ~arch. Also, devs are not required to read or even be subscribed to -dev. Agreed. Implicit in all this is that I'm going to have to make a bit of noise (and probably attempt and get it shoved out via gwn) prior to doing it, so that I don't have ~100 devs who didn't hear the news looking in my direction. What other changes are you guys thinking of regarding profiles? -- Chris Gianelloni Release Engineering - Strategic Lead/QA Manager Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
On Mon, 2005-08-29 at 17:34 -0400, [EMAIL PROTECTED] wrote: I think Brian mentioned /etc/portage/profile and other fun portage tricks to mess with the default profile. If you think the profile shouldn't be changed then don't make it a mutable option. If you think that bugs where people fubared their profile are a problem then write a tool to print out that information and have the user present it to you when they file the bug. What? I was saying that *we* shouldn't have to waste *our* time making profiles we won't use. End of discussion. If you want a warner6-wuz-here profile under default-linux/x86 that turned off all the USE flags and only enabled USE=yes-I-really-only-want-this-one-USE then you could. We won't stop you, nor will we care to stop you. We wouldn't even complain. As far as maintainability, you could always make a profile outside of the default-linux tree ( default-gentoo/* ) and construct the smaller/faster/better profiles there. That means anyone that wants to No. *I* could not because *I* think it is a waste of time. I care about exactly one profile, in honesty, the one I use to build the release. If there were 10,000 other profiles, I wouldn't care. That being said, I wouldn't want anyone changing the profile I used to build the release. If I do a stage3 today and a stage3 tomorrow, both using the same profile, then do an emerge gnome on each, I would expect it to have the same USE flags. This is a simple matter of reproducibility and predictability. customize can change the symlink and you ( releng ) still get your pristine release profiles ( which IMHO is a silly notion, but I don't manage your bugs, so whichever way you like ;) ). Going on that notion, I am really shooting for predictability with the profiles that are managed by releng. you could also do default-linux/x86/2005.1/release or whatnot if you want to maintain that as well. Why? Would you not expect the 2005.1 Handbook plus the 2005.1 media plus the 2005.1 profile to produce a 2005.1 system? Why would I need a release sub-profile to distinguish it as a release? Is that not completely redundant? -- Chris Gianelloni Release Engineering - Strategic Lead/QA Manager Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
On Mon, 29 Aug 2005 17:43:35 -0400 Chris Gianelloni [EMAIL PROTECTED] wrote: | There's nothing stopping you from creating a | default-linux/x86/ferringb profile and doing whatever you wish in it, | but editing default-linux/x86/2005.1 without speaking with releng | would be considered taboo. Shouldn't this fall under the x86 arch team rather than releng? The arch teams maintain the other profiles, and whilst the arch's releng contact will certainly be doing some of the changes, so will other arch team members who do not get deeply involved in the release process... -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir
On Mon, Aug 29, 2005 at 05:48:20PM -0400, Chris Gianelloni wrote: What other changes are you guys thinking of regarding profiles? That would be Marius's department. I'm not willing (personally) to look at revamping profiles till rewrite is finished. At that point, new profile's should be able to be just plugged in; I don't care to bite off any more then I already have ;) Offhand, I'd expect the removal of package filtering in the packages files (package.mask provides this already), probably a bit of renaming of packages also. Why? Packages is vague. Stupid reason to change it I realize, but packages makes sense in a single set, 'system' set view. Rearrange it so that packages isn't auto assumed to be system, stick it in a subdir fex, and you would give profiles the capability to arbitrarily define their own sets. Aside from that, the parent implementation could stand a tweak or two. Further, assuming metapkg goes through, virtual is obsoleted. The inclusion of GRP_STAGE23_USE also bugs me a bit; yes it works right now, but what happens when you need to push more info in? Seems like it should be contained on it's own. Either way, just a couple of things off the top of my head. My main push for it is cleanup for stand alone repositories, and ensuring anything people attempt with profiles doesn't have side effects on the raw repositories metadata. ~harring pgpYLVPpS4XfW.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
On Mon, Aug 29, 2005 at 05:43:35PM -0400, Chris Gianelloni wrote: snip Re: not shoving work onto you, complicating your job, etc, I agree, and actually is what I was getting at in the badly worded section below My point is pretty simple, why should we spend a bunch of time maintaining something that is designed from the start to be customized, and most likely won't even be used anyway? That's the issue; the profiles in their current form are customizable only in the ability to negate a collection of flags. Negating the whole beast is another story due to the desktop cruft being shoved into the arch subprofiles. Sorry, but this didn't make a bit of sense to me. Perhaps you could reword it? Basically stating that if I want the minimal 2005.1 x86 profile to build my own server profile off of, I can't really use the existing default-linux/x86/2005.1 ; Why? Mainly due to the fact that I would be forced to reverse a *lot* of stuff, use flags mainly, to get it back down to a minimal profile. That's what I mean by lack of customization; it can be done, but it's not optimal, vs say inheriting a base default/x86/2005.1 that holds just system defaults (pam, cflags, etc). If I were to implement a server profile from existing, I'd probably tag in -* to the use, and add the use flags I explicitly want; that's not really the best way to use the profiles inheritance capabilities though :) Profile customization occurs, /etc/portage/profiles exists for this reason; the 2005.1 profile (fex) is probably *rarely* ran exactly as y'all have it specified considering we do have user level use flags, tweaking the hell out of '05.1. You would be surprised at the number of people that use GRP and rarely, if ever, change their USE flags. I wish I had numbers, but I don't. Anyway, the default set of USE flags seems to be a pretty perfect mix for most people. It gives packages that work as expected, and is geared toward a desktop system. Without any more specific examples of what you're trying to point out, I'm just not seeing it. Key thing to note, neither of us have figures :) Beyond that, I'm not after castrating the defaults that exist, I'm after sticking a level of indirection, a subprofile into the releng profile inheritance chain so that if I *want* a minimal profile (as you use), I can get it without having to resort to -* and tracking all of the changes myself. It's a time saving effort; add multiple inheritance in, and it's easy to do (win/win). Aside from mild disagreement on views, as was stated in previous emails, multiple inheritance I tend to think is required to minimize the work for y'all; what I want you guys to do (or I'll do myself) is chunk the suckers up so people after a minimal base for running it themselves, or building up their own subprofile can do so. Not after jamming maintenance nightmares on you, which without multiple inheritance, might be a bit. I know that I won't be spending *my* time making any profile other than the defaults used for building the release. Anyone is welcome to build profiles for anything else that they might want, but since the release team doesn't use it, we shouldn't be forced to waste our time on it. Agreed, although I'd posit that when/if multiple inheritance is added, y'all take advantage of it (break up the settings into base and desktop) so that others can use your base work instead of reinventing the wheel. ~harring pgpfFtin4sgb9.pgp Description: PGP signature
[gentoo-dev] Updating package.use automatically
For those of you who like having only a small amount of USE flags defined in make.conf along with -*, keeping package.use updated (as to not break --newuse, etc) can be a laborious task (assuming you even bother in the first place). Portage isn't supposed to touch users configuration files, so you can consider this one a hack. The following bashrc will do all the work for you, enjoy. http://dev.gentoo.org/~port001/configs/bashrc Regards, Ian. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] PATCH: initial EAPI awareness
On 08/27/05 Brian Harring wrote:
Hola.
Attached is a patch that
A) adds EAPI awareness to portage; mainly, if 0, complain and be
unwilling to merge the package
Actually I just wrote also a patch for it (for 2.1), however instead of
complaining I just masked them (without unmask ability), just add a
check to gvisible() and getmaskingstatus() (actually just calling
dbapi.eapicheck()). That way it should be more transparent to users IMO.
Won't stop people from using ebuild(1) though.
Marius
PS: I'm aware that the cache changes probably aren't 100% correct.
--
Public Key at http://www.genone.de/info/gpg-key.pub
In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.
--- pym/portage.py.org 2005-08-23 03:23:59.0 +0200
+++ pym/portage.py 2005-09-02 05:49:50.0 +0200
@@ -91,7 +90,7 @@
MOVE_BINARY, PRELINK_BINARY, WORLD_FILE, MAKE_CONF_FILE, MAKE_DEFAULTS_FILE, \
DEPRECATED_PROFILE_FILE, USER_VIRTUALS_FILE, EBUILD_SH_ENV_FILE, \
INVALID_ENV_FILE, CUSTOM_MIRRORS_FILE, SANDBOX_PIDS_FILE, CONFIG_MEMORY_FILE,\
- INCREMENTALS, STICKIES
+ INCREMENTALS, STICKIES, EAPI_COMPATIBLE
from portage_data import ostype, lchown, userland, secpass, uid, wheelgid, \
portage_uid, portage_gid
@@ -2057,6 +2056,13 @@
'return: [0,=sys-libs/bar-1.0,http://www.foo.com;] or [] if mycpv not found'
raise NotImplementedError
+ def eapicheck(self, mycpv, verbose=0):
+ myeapi = self.aux_get(mycpv, [EAPI])[0]
+ rval = (myeapi in ['']+EAPI_COMPATIBLE.split())
+ if not rval and verbose:
+ writemsg(Warning: EAPI check failed for %s (has EAPI '%s') % (mycpv, myeapi))
+ return rval
+
def match(self,origdep,use_cache=1):
mydep=dep_expand(origdep,mydb=self)
mykey=portage_dep.dep_getkey(mydep)
@@ -2667,9 +2673,9 @@
'DEPEND','RDEPEND', 'SLOT', 'SRC_URI',
'RESTRICT', 'HOMEPAGE', 'LICENSE', 'DESCRIPTION',
'KEYWORDS', 'INHERITED', 'IUSE', 'CDEPEND',
- 'PDEPEND', 'PROVIDE',
+ 'PDEPEND', 'PROVIDE', 'EAPI'
'UNUSED_01', 'UNUSED_02', 'UNUSED_03', 'UNUSED_04',
- 'UNUSED_05', 'UNUSED_06', 'UNUSED_07', 'UNUSED_08',
+ 'UNUSED_05', 'UNUSED_06', 'UNUSED_07',
]
auxdbkeylen=len(auxdbkeys)
@@ -2737,7 +2743,7 @@
raise KeyError(CPV %s does not exist % mycpv)
mycp=mysplit[0]+/+mysplit[1]
- if settings.pmaskdict.has_key(mycp):
+ if package.mask in getmaskingstatus(mycpv) and settings.pmaskdict.has_key(mycp):
for x in settings.pmaskdict[mycp]:
if mycpv in self.xmatch(match-all, x):
pmaskfile = open(settings[PORTDIR]+/profiles/package.mask)
@@ -2768,6 +2774,11 @@
rValue = []
+ # EAPI checking
+
+ if not db[/][porttree].dbapi.eapicheck(mycpv):
+ rValue.append(EAPI)
+
# profile checking
revmaskdict=settings.prevmaskdict
if revmaskdict.has_key(mycp):
@@ -3286,7 +3297,7 @@
return newlist
def gvisible(self,mylist):
- strip out group-masked (not in current group) entries
+ strip out group-masked (not in current group) entries and entries with wrong EAPIs
global groups
if mylist==None:
return []
@@ -3297,7 +3308,7 @@
#we need to update this next line when we have fully integrated the new db api
auxerr=0
try:
-myaux=db[/][porttree].dbapi.aux_get(mycpv, [KEYWORDS])
+myaux=db[/][porttree].dbapi.aux_get(mycpv, [KEYWORDS, EAPI])
except (KeyError,IOError,TypeError):
continue
if not myaux[0]:
@@ -3305,6 +3316,7 @@
#print !!! No KEYWORDS for +str(mycpv)+ -- Untested Status
continue
mygroups=myaux[0].split()
+ myeapi=myaux[1]
pgroups=groups[:]
cp = portage_dep.dep_getkey(mycpv)
if cp in pkgdict:
@@ -3334,7 +3346,7 @@
if gp[0] != -:
match=1
break
- if match:
+ if match and db[/][porttree].dbapi.eapicheck(mycpv):
newlist.append(mycpv)
return newlist
--- bin/ebuild.sh.org 2005-08-23 03:23:46.0 +0200
+++ bin/ebuild.sh 2005-09-02 04:29:37.0 +0200
@@ -640,6 +640,7 @@
[ $CDEPEND:-unset} != unset ] speak CDEPEND=$(echo $CDEPEND)
[ $PDEPEND:-unset} != unset ] speak PDEPEND=$(echo $PDEPEND)
[ $PROVIDE:-unset} != unset ] speak PROVIDE=$(echo $PROVIDE)
+ [ $EAPI:-unset} != unset ] speak EAPI=$(echo $EAPI)
speak 'end_keys'
set +f
;;
--- bin/ebuild-default-functions.sh.org 2005-08-23 03:24:26.0 +0200
+++ bin/ebuild-default-functions.sh 2005-09-02 04:30:05.0 +0200
@@ -344,6 +340,7 @@
echo $RDEPEND RDEPEND
echo $RESTRICT RESTRICT
echo $SLOT SLOT
+ echo $EAPI EAPI
echo $USE USE
export_environ ${PORTAGE_BUILDDIR}/build-info/environment.bz2 'bzip2 -c9'
cp ${EBUILD} ${PF}.ebuild
--- pym/portage_const.py.org 2005-08-23 01:18:53.0 +0200
+++ pym/portage_const.py 2005-09-02 05:44:43.0 +0200
@@ -63,3 +63,4 @@
CVS_BIN = /usr/bin/cvs
EBUILD_PHASES = setup unpack compile test install preinst postinst prerm postrm
Re: [gentoo-portage-dev] PATCH: initial EAPI awareness
On Saturday 27 August 2005 12:53, Brian Harring wrote: Hola. Attached is a patch that A) adds EAPI awareness to portage; mainly, if 0, complain and be unwilling to merge the package B) tweaks to portage_db_flat, addition of portage_db_metadata, and portage_db_flat_hash I just realised that there are possible issues with incompatble eclasses and ebuilds. What (should) happen(s) when an eclass supports EAPI=1 with src_configure and src_make, while the ebuild supports/expects EAPI=0 with src_compile. This means that in some way eclasses should state which EAPI versions they support. Possibly with making EAPI a space separated list of api's accepted. This would mean some checking in the inherit code AND that EAPI in the ebuild should be defined before the inherit. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgprAJqRnIcTX.pgp Description: PGP signature
