Re: [gentoo-dev] Re: Hold on portage feature requests
On Monday 01 August 2005 02:07, R Hill wrote: Alec Joseph Warner wrote: Donnie Berkholz wrote: Are you having a tough time filtering out enhancements in your queries or something? I don't understand how feature requests could possibly interfere with anything besides other enhancements. Many of the enhancements aren't marked as such, Then they should be. ;) There's nothing wrong with reclassifying your bugs to make it easier to manage them. The features are there exactly for this reason - so critical bugs don't get drowned out by less important bugs or enhancement requests. I guess it doesn't really matter, but it would have been just as easy to set the severity of these bugs to min or enh rather than close them, and then they would still show up on a simple search. Several people have asked why the available bug attributes don't suffice. The reasons are quite simple: 1) Feature requests won't be addressed any time soon. It was suggested that closing the bugs as LATER will cause more duplicates and effect more work. I deferred (not closed!) 150 feature requests at least a third of which were duplicates. Because feature requests are not being addressed, they are piling up and users are not able to find duplicates with the bugs being open anyway. However, publicizing that feature requests have been put on hold has had the desired affect. There have been no new requests this past week. 2) Every bug change has to be dealt with at least twice. I try to monitor bugs via the emails sent as much as possible. With the amount generated by new feature requests and the numerous +1 posts on existing requests, it is simply not feasible to parse the incoming mail without making at least two passes. Here, I can hear people suggesting that I just /dev/null the email and monitor bugs via bugzilla. My answer? Opening listing 100+ bugs (that's assuming the bugs were properly categorized (which they are not) - there is actually about 300 bugs open other than the 150 feature requests closed) as well as the bugs is a slow painful process on a 32000bps connection. 3) To be able to utilize bug mails beyond notification. I've written a simple script to create a report of what bugs have changed and how many times within a set period. I'm posting the results to the portage mailing list in order to try and fish out some fresh blood. Having these reports littered with feature requests means that the important stuff that is causing users problems is hidden between all the oh wouldn't it be lovely bugs. Yes, this has also been successful already. There's been patches posted on various bugs that actually fix the root cause of the problems outlined. 4) Less user frustration. The two most frequent comments at the moment are is anybody looking at this? and it's been over a year! Users knowing what's going on and especially finding that their minor bugs are starting to gain some activity can only be a good thing. I could figure out some more reasons if it's really necessary, but the past week has shown that the path chosen (even if there is some better path) is not a bad one as things are working out well thus far. -- Jason Stubbs pgpcc0nq6l0qk.pgp Description: PGP signature
Re: [gentoo-dev] Valid Profiles
On Sun, 2005-07-31 at 10:59 -0400, Ned Ludd wrote: - x86/linux24 (deprecated) - x86/linux26 (deprecated) What should we do with deprecated profiles? Should we still be checking against them? I would think we would, but what do the rest of you think? -- 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] Valid Profiles
On Monday 01 August 2005 10:15 am, Chris Gianelloni wrote: On Sun, 2005-07-31 at 10:59 -0400, Ned Ludd wrote: - x86/linux24 (deprecated) - x86/linux26 (deprecated) What should we do with deprecated profiles? Should we still be checking against them? I would think we would, but what do the rest of you think? speaking of which, i had an idea to clean up all that crap, i just forgot to post it a while back ... gentoo-x86/profiles/ $ tree obsolete obsolete |-- README |-- alpha | |-- deprecated | `-- make.defaults |-- amd64 | |-- deprecated | `-- make.defaults |-- hppa | |-- deprecated | `-- make.defaults |-- ia64 | |-- deprecated | `-- make.defaults |-- mips | |-- deprecated | `-- make.defaults |-- ppc | |-- deprecated | `-- make.defaults |-- ppc64 | |-- deprecated | `-- make.defaults |-- sparc | |-- deprecated | `-- make.defaults `-- x86 |-- deprecated `-- make.defaults 9 directories, 19 files then we can punt all the flat profiles and if a user needs an upgrade path, they can symlink to these in the meantime -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Valid Profiles
On Sun, 2005-07-31 at 20:21 +0200, Benedikt Boehm wrote: On Sunday 31 July 2005 16:11, Chris Gianelloni wrote: ka0ttic reminded me about the idea of adding all of the valid profiles to profiles.desc now that portage 2.0.51.22 has gone stable. Well, I need you guys to give me a list of what is valid or not. I have a pretty good idea of what is valid under default-linux, as far as the default profiles go, but need to know which profiles are development profiles. I especially need to know which profiles are valid for projects like embedded, hardened, and *bsd. vserver/* Not true. vserver itself is not a valid profile. This is exactly why I am asking for this information. From what I can tell, only vserver/x86 is valid. -- 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] Valid Profiles
On Jul 31, 2005, at 9:11 AM, Chris Gianelloni wrote: I especially need to know which profiles are valid for projects like embedded, hardened, and *bsd. Here is the state of macos profiles: Valid: default-darwin/ - macos/10.3 - macos/10.4 - macos/progressive Deprecated: default-macos/* default-macos-10.3/ default-macos-10.4/ Thanks, -- Chris Gianelloni Release Engineering - Strategic Lead/QA Manager Games - Developer Gentoo Linux -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ekeyword and ordering
On Sat, 2005-06-11 at 14:46 -0400, Aron Griffis wrote: foser wrote: [Sat Jun 11 2005, 04:15:22AM EDT] Arch keywords are concepts and as such may not primarily be dealt as a an alphabetical list but as words in a sentence, there is no abc order in sentences. Foser, no offense intended, but you started out in this thread making a couple good points. However this is completely off the wall. The KEYWORDS list isn't a sentence. The post I replied to was full of far-fetched reasoning, I just made a similar post. If you have to search, you'll have to scan anyway, exact position is not a guarantee for certainty because not every pack is available on every arch, it's not like you can go without scanning. Doesn't change the point that scanning in alpha order is easier than scanning append order. Last, this only holds to some extent true for people in countries with alphabetic scripts, outside that limited part of the globe people are not as proficient in ordering alphabetically. AFAIK, all Gentoo developers are fluent English speakers, even if for some it isn't their first language. Fluent, right. Try some of the cjk people. Not really. Anyway, it doesn't matter, if you didn't grown up with the alphabet, you really don't know the ordering by heart like western people do. In spoken language it doesn't matter what the order is, it is totally arbitrary. Also, realistically it's probably only 1st language for maybe half of the devs these days. A certain amount of uncertainty in order actually might prove to be effective in having everyone who deals with keywords actually really check all keywords and not depend on assumptions, which both 'error' cases you mention seem to be caused by. Maintaining a behavior that encourages mistakes, in hopes that the extra effort required will prevent those mistakes? This cannot possibly be a good approach... You assume here suddenly that it encourages mistakes, there is no such evidence presented here or ever was, there is however evidence to the contrary where the continues shifting of orders (within packages) caused problems (the thing I disliked about this whole situation to begin with). I actually suggest that the opposite might be true, a certain degree of uncertainty (between packages) prompts caution and might prove to be more error-free. Sure it's all a bit far fetched, but so was the post that suggested that there was some grand ergonomic idea behind this arbitrary change. I did not in this thread challenge the ordering (who made that up?), I challenged the way it got 'introduced'. I just got ticked off by the 'scientific basis' that suddenly was presented as the big reason behind it. To recap, it was the arbitrary /ordering change/ of a select group of individuals that created problems within packages, not the one or the other /order/. - foser signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] ekeyword and ordering
Catching up on your inbox, foser? ;-) foser wrote:[Mon Aug 01 2005, 01:06:10PM EDT] On Sat, 2005-06-11 at 14:46 -0400, Aron Griffis wrote: foser wrote:[Sat Jun 11 2005, 04:15:22AM EDT] Arch keywords are concepts and as such may not primarily be dealt as a an alphabetical list but as words in a sentence, there is no abc order in sentences. Foser, no offense intended, but you started out in this thread making a couple good points. However this is completely off the wall. The KEYWORDS list isn't a sentence. The post I replied to was full of far-fetched reasoning, I just made a similar post. Actually, later I thought maybe I understood your sentence parallel. Your point was that when the KEYWORDS list is scrambled from its original order, it loses information, similar to when the words in a sentence are scrambled. Sorry, I should have been more open-minded in my first reading. If you have to search, you'll have to scan anyway, exact position is not a guarantee for certainty because not every pack is available on every arch, it's not like you can go without scanning. Doesn't change the point that scanning in alpha order is easier than scanning append order. Last, this only holds to some extent true for people in countries with alphabetic scripts, outside that limited part of the globe people are not as proficient in ordering alphabetically. AFAIK, all Gentoo developers are fluent English speakers, even if for some it isn't their first language. Fluent, right. Try some of the cjk people. Not really. Anyway, it doesn't matter, if you didn't grown up with the alphabet, you really don't know the ordering by heart like western people do. In spoken language it doesn't matter what the order is, it is totally arbitrary. Also, realistically it's probably only 1st language for maybe half of the devs these days. IMHO (and I do mean humble, because I could be wrong) the majority of portage tree commits are coming from people who are fluent in a Western tongue. For many people the alpha ordering makes things easier, and most of the others don't care. A certain amount of uncertainty in order actually might prove to be effective in having everyone who deals with keywords actually really check all keywords and not depend on assumptions, which both 'error' cases you mention seem to be caused by. Maintaining a behavior that encourages mistakes, in hopes that the extra effort required will prevent those mistakes? This cannot possibly be a good approach... You assume here suddenly that it encourages mistakes, there is no such evidence presented here or ever was, there is however evidence to the contrary where the continues shifting of orders (within packages) caused problems (the thing I disliked about this whole situation to begin with). I actually suggest that the opposite might be true, a certain degree of uncertainty (between packages) prompts caution and might prove to be more error-free. Sure it's all a bit far fetched, but so was the post that suggested that there was some grand ergonomic idea behind this arbitrary change. You're right, I don't have evidence to present. My suspicion is that uncertainty doesn't lead to caution in this case. I didn't intend to make any more assumptions than you were making. I did not in this thread challenge the ordering (who made that up?), I challenged the way it got 'introduced'. I just got ticked off by the 'scientific basis' that suddenly was presented as the big reason behind it. To recap, it was the arbitrary /ordering change/ of a select group of individuals that created problems within packages, not the one or the other /order/. Oh, I thought for sure that you were arguing that one order was better than the other. If you weren't, why have you talked so much about it? It seems like if you don't care about the ultimate ordering, then it would be better to ignore that part of this thread, wouldn't it? Regarding the way the change was made, I apologized at the beginning of this thread and stated that I would not make a future change like that without going through a discussion first. As the maintainer of ekeyword, I made the change unilaterally without taking into account how controversial it would be. It seems like the thread could have ended there, eh? Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpqkmKaXzqbk.pgp Description: PGP signature
Re: [gentoo-dev] Modular X plans
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: | On Mon, 01 Aug 2005 13:54:27 -0700 Donnie Berkholz | [EMAIL PROTECTED] wrote: | | Until such time as that becomes possible for everyone to do, the | | x11-libs metabuild will PROVIDE virtual/x11. But realize that not | | everybody will have or want all the X libraries installed, when they | | only need a few. | | I'd suggest keeping virtual/x11 as a 'full, complete, everything X', and | adding in a few new virtuals to take care of the common dependency | configurations. Remember, versioned virtual deps should be eschewed... The virtual will retain its meaning, as I have always publicized it to be the libraries and not the X server or anything else. That's why kdrive doesn't provide it, among other things. Having x11-libs provide the virtual should also work the best for headless X servers, which have been in fairly high demand. Your suggestion of adding a few new virtuals is a good idea, but I think the metabuilds for libraries, drivers, etc. can substitute for it. It's not clear to me that there are many common configurations that could be dealt with cleanly by a virtual in a better way, that also retains a low level of complexity in the ebuilds. Frankly, the only reason the virtual will even exist after the 7.0 release is so people have time to play catch-up. I don't want the virtual to stay in use. If you could provide some examples of how the virtuals would be more helpful to other devs, I'd enjoy hearing (or reading) them. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC7pK5XVaO67S1rtsRAq+gAJ9uwg60S2OTt982efkLyPXcI6ZXlgCaAmyA buyybKLsk3fRCKOZ7nfsP8w= =qEkI -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X plans
On Mon, 01 Aug 2005 14:23:06 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: | Your suggestion of adding a few new virtuals is a good idea, but I | think the metabuilds for libraries, drivers, etc. can substitute for | it. It's not clear to me that there are many common configurations | that could be dealt with cleanly by a virtual in a better way, that | also retains a low level of complexity in the ebuilds. Well... What I was mainly thinking (and assuming we don't have the new virtuals system by whenever this becomes relevant) is that a metapackage could represent, say, the core x11 libraries as provided by xorg. This is all well and good, but there are other X implementations out there. It could well save a lot of work in the long term if deps were generally upon the core x11 libraries instead. | Frankly, the only reason the virtual will even exist after the 7.0 | release is so people have time to play catch-up. I don't want the | virtual to stay in use. Is it your assumption that in the future xorg-x11 will be the only serious X server? *shrug* I realise we make similar assumptions about a lot of packages, but X is a) an at least vaguely standard protocol, b) heavily depended upon and c) implemented by more than one vendor. -- Ciaran McCreesh -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X plans
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: | Well... What I was mainly thinking (and assuming we don't have the new | virtuals system by whenever this becomes relevant) is that a metapackage | could represent, say, the core x11 libraries as provided by xorg. This | is all well and good, but there are other X implementations out there. | It could well save a lot of work in the long term if deps were generally | upon the core x11 libraries instead. But see, that's the thing; no packages should just generally say Give me the X libraries other than temporarily. They should be specifically demanding upon the exact libraries they require. | Is it your assumption that in the future xorg-x11 will be the only | serious X server? My assumption is that if there's another fork, it will be easier to deal with || ( xorg-libfoo forkx-libfoo ) than a virtual for every single package X provides. | *shrug* I realise we make similar assumptions about a lot of packages, | but X is a) an at least vaguely standard protocol, b) heavily depended | upon and c) implemented by more than one vendor. Indeed. But what I've begun to discover is that virtuals aren't always the best solution when there is more than one provider, much less when that's a largely hypothetical question. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC7pn8XVaO67S1rtsRApYwAJ4wTzdCv2E8Lf9Yu5rjEVC+tZIGdACg6cOT yNxBHXc4DpBh3e8r76pBFrc= =vWPO -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X plans
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
| On Mon, 01 Aug 2005 14:54:04 -0700 Donnie Berkholz
| [EMAIL PROTECTED] wrote:
| | Ciaran McCreesh wrote:
| | But see, that's the thing; no packages should just generally say Give
| | me the X libraries other than temporarily. They should be
| | specifically demanding upon the exact libraries they require.
|
| Hrm. Is this going to be sanely doable by your average dev? How long
| a dep string would we be having in typical cases? How about in bad
| cases?
It shouldn't be difficult in most cases, for those capable of finding
linker lines in a build.
I wrote a quick one-liner that works reasonably well on a couple of
tests, but could use a little tweaking. Just set log to your build log
beforehand.
for linkline in $(grep ' \-l[a-zA-Z]' ${log}); do if [[ ${linkline} =~
-l[a-zA-Z] ]]; then echo $linkline; fi; done | sort | uniq
I ran it on gedit and thunderbird and got largely reasonable output. In
gedit's case, there would be 5
X library dependencies. In thunderbird's case, there would be 9.
| | | Is it your assumption that in the future xorg-x11 will be the only
| | | serious X server?
| |
| | My assumption is that if there's another fork, it will be easier to
| | deal with || ( xorg-libfoo forkx-libfoo ) than a virtual for every
| | single package X provides.
|
| So X deps will be by package ('either xorg-libfoo or forkx-foo or
| sgi-x'), rather than by concept in the future?
This makes more sense to me, particularly given the objection people
have to adding new virtuals. Adding a hundred or two wouldn't make them
happy.
| | | *shrug* I realise we make similar assumptions about a lot of
| | | packages, but X is a) an at least vaguely standard protocol, b)
| | | heavily depended upon and c) implemented by more than one vendor.
| |
| | Indeed. But what I've begun to discover is that virtuals aren't always
| | the best solution when there is more than one provider, much less when
| | that's a largely hypothetical question.
|
| Mmm, possibly true. For the big things though, I was hoping we could
| switch more towards depending by concept rather than by implementation,
| especially once we get improved virtuals. The current X situation is
| sort of a concept dependency -- moving away from that could arguably be
| seen as a regression from one perspective.
It could be, but X is no longer a big thing. It's a few hundred small ones.
Thanks for your ideas,
Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFC7qP6XVaO67S1rtsRAhAQAKC2hBxwGSV3RJDZaKK/bAm9fF2kDgCeP7qo
vPyx7bXz6vKDWEEGtI4LMng=
=ZPiY
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X plans
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
On Mon, 01 Aug 2005 14:54:04 -0700 Donnie Berkholz
[EMAIL PROTECTED] wrote:
| Ciaran McCreesh wrote:
| | Well... What I was mainly thinking (and assuming we don't have the
| | new virtuals system by whenever this becomes relevant) is that a
| | metapackage could represent, say, the core x11 libraries as
| | provided by xorg. This is all well and good, but there are other X
| | implementations out there. It could well save a lot of work in the
| | long term if deps were generally upon the core x11 libraries
| | instead.
|
| But see, that's the thing; no packages should just generally say Give
| me the X libraries other than temporarily. They should be
| specifically demanding upon the exact libraries they require.
Hrm. Is this going to be sanely doable by your average dev? How long
a dep string would we be having in typical cases? How about in bad
cases?
The more formal the depstring, the quicker the packages build ( using
only needed packages instead of lumping them in one group ). This is
essentially what the DEPEND should be, just what the packages needs to
compile and run. This especially benefits embedded targets who need a
bare-bones set of libraries and nothing else.
| | Is it your assumption that in the future xorg-x11 will be the only
| | serious X server?
|
| My assumption is that if there's another fork, it will be easier to
| deal with || ( xorg-libfoo forkx-libfoo ) than a virtual for every
| single package X provides.
So X deps will be by package ('either xorg-libfoo or forkx-foo or
sgi-x'), rather than by concept in the future?
I think concepts are important and abstract complexity from a packages
DEPEND. However, having the DEPEND be accurate is important as well.
This almost reeks of the USE group GLEP being applied here as well.
Setting up DEPEND-set would be great for this, although it is difficult
to imagine sets that can be shared between many packages. eclasses are
marginally decent for this right now anyway.
| | *shrug* I realise we make similar assumptions about a lot of
| | packages, but X is a) an at least vaguely standard protocol, b)
| | heavily depended upon and c) implemented by more than one vendor.
|
| Indeed. But what I've begun to discover is that virtuals aren't always
| the best solution when there is more than one provider, much less when
| that's a largely hypothetical question.
The problem with the individual approach is if I wanted to run XFree,
or a competing X implementation, I have to add about 200+ packages to
/etc/portage/package.provided. This is not clean at all; it's hideous.
If I add the meta-build to /etc/portage/package.provided it just means
that I am managing the meta-ebuild and it is valid to count it as
installed for dep calculation. This is not true of any of the
dependencies of the meta-ebuild however. Thats just what I remember fro
m discussion about it, so correct me if it's wrong ;)
Mmm, possibly true. For the big things though, I was hoping we could
switch more towards depending by concept rather than by implementation,
especially once we get improved virtuals. The current X situation is
sort of a concept dependency -- moving away from that could arguably be
seen as a regression from one perspective.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iQIVAwUBQu6u+GzglR5RwbyYAQI+Jw/+NZ1e0S687AjvBFwbK9qOGekgjd37WIxk
w5Y+t66OgULeU9XTNRW9hLY63Eg7q5nOByAH4HyUwntrgPTHr9s3c/GhP80f4Jwa
cDfhSnR6axMaNS5CgmZ/DyrfVGlCPTa6JWWdjt9rTcuFIIx1/SbMxcGcg0Lv7JJE
SCGchwugKOjoy+uhsEDVh6/nUhzdb/Nj5wsz/CbNdFPtnob87w/iTB0AVcNyXn2T
fJ4q5Lvrmb1/CyUso26am2dpAw+0xY0kmWSDzBxiMPbP06zX39ZrMEkTxLfsQoZO
ISVQmQ5K532qWpziSaktDtzKdxcw+vJU9ObelJX2deGyurl7mUxfjALoQ702eSI7
1Bmx9QqvtGWWmzDRtw1VNXr0645QKX+HFsPR1o9vZHqT2orKLs6FcHTjNKr6nCRx
Y0ixYRSSwk5Ik3WeG/3ydNJs45NrcOa9qE66uU9OIvM+ONIxVTey6WpF/XGHqcC/
6K8QiQw1eJV5qIK3vH72dZ+B+Bk9fYX3Pn+q7gVLYHFekCIVwxZu0R6wWkQIcgAt
fb6WLILnduo4wvDdgRToTswdaQbxP5qaX7Y4uB1PerXDgwG4/kVK+ZhYVjhJpnN2
nj38OBLQZUJ0WaiReYygiFz1ePiaAWG4Fy2uH/kNUFsHt0QvjFnzkw+7s9/dst6t
j42vluI+/fk=
=O+1e
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] devfs is dead, let's move on
Greg KH wrote: Oops, yes, the 064 release fixed that. Sorry for not updateing the bugzilla entry. That is now taken care of. Just out of curiosity, know what happened to cause that? --Kumba -- Gentoo/MIPS Team Lead Gentoo Foundation Board of Trustees Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere. --Elrond -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X plans
On Mon, 01 Aug 2005 19:23:37 -0400 Alec Warner [EMAIL PROTECTED] wrote: | Hrm. Is this going to be sanely doable by your average dev? How | long a dep string would we be having in typical cases? How about in | bad cases? | | The more formal the depstring, the quicker the packages build ( | using | only needed packages instead of lumping them in one group ). This is | essentially what the DEPEND should be, just what the packages needs to | compile and run. This especially benefits embedded targets who need a | bare-bones set of libraries and nothing else. The problem is... By hard-coding a bunch of xorg packages, you're making your DEPEND *less* accurate. Most packages will build just fine with other X implementations. Mmm, but for now this is pretty much a pointless argument. We're not a real metadistribution yet :) | I think concepts are important and abstract complexity from a | packages | DEPEND. However, having the DEPEND be accurate is important as well. | This almost reeks of the USE group GLEP being applied here as well. | Setting up DEPEND-set would be great for this, although it is | difficult to imagine sets that can be shared between many packages. | eclasses are marginally decent for this right now anyway. GLEP 37 allows that, in effect. Speaking of GLEP 37... Jason -- I'm assuming that virtual-x11/ (say) would be possible? | The problem with the individual approach is if I wanted to run | XFree, | or a competing X implementation, I have to add about 200+ packages to | /etc/portage/package.provided. This is not clean at all; it's | hideous. If I add the meta-build to /etc/portage/package.provided it | just means that I am managing the meta-ebuild and it is valid to count | it as installed for dep calculation. This is not true of any of the | dependencies of the meta-ebuild however. Thats just what I remember | fro m discussion about it, so correct me if it's wrong ;) Providing a specific metapackage is a bad idea. What if a package really does depend upon xorg? Providing a specific concept would be better. Whether such a thing is implementable currently is up for debate... -- Ciaran McCreesh -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] devfs is dead, let's move on
On Mon, Aug 01, 2005 at 07:40:03PM -0400, Kumba wrote: Greg KH wrote: Oops, yes, the 064 release fixed that. Sorry for not updateing the bugzilla entry. That is now taken care of. Just out of curiosity, know what happened to cause that? Unaligned data accesses. Was fixed by: http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=commit;h=422d5becc339304805bbe1e359f6389633036a98 thanks, greg k-h -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] The dreaded debug use flag/eclass
On Monday 01 August 2005 09:22 pm, Alec Warner wrote: Many people do not like the fact that a USE flag changes CFLAGS. Although there are other USE flags that do this too ( pic comes to mind in a couple ebuilds, checkpassword fex ) they are a minority compared to debug. your USE=pic example is wrong, it does not change CFLAGS (and if your package does, it is broken) -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] The dreaded debug use flag/eclass
On Monday 01 August 2005 10:43 pm, Danny van Dyk wrote: chillispot at least is not wrong. If USE=pic is set, it compiles _only with_ -fPIC, ommiting to compile files twice and effectivly telling libtool not to produce a normal static library. not really chillispot doesnt build/install any libraries -mike -- gentoo-dev@gentoo.org mailing list
