Re: [gentoo-dev] perl, sed and non-gsed
On Apr 7, 2005, at 7:33 am, Luca Barbato wrote: Brian Harring wrote: Problem with the preference you have above is you're considering portage as the primary pkg manager/authority for that system, which it isn't on osx. If a tool is broken you change it, the apple toolchain and probably userspace could enjoy some improvements. Do you actually use OS X? This is not a case of sed being broken on BSD / OS X - on a Mac everything works fine out of the box, and users can use standard tools, many of which are provided, just like on any other *NIX. This is a case where the use of Gentoo would make compiling packages easier & more convenient for OS X users, and Gentoo prefers a non-standard tool; the Apple install is not "broken" and many people would not consider messing with it to be beneficial. Stroller. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: New category proposal
On May 11, 2005, at 8:10 pm, Ciaran McCreesh wrote:
* Unique ID strings for packages, zynot style. Messy as hell though,
DEPEND="foo/bar {12379812AD7382164BD87678652438FC65E43A2}" doesn't have
the same kind of ring to it...
Maybe I'm just a messy person, but I really like this. It prevents
upstream naming collisions & opens multiple categories per package
completely. Mr Harring will hate it, but the rest of us will use
`esearch -o "%p\n" "" | grep -e category -e keyword`.
Stroller.
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: New category proposal
On May 12, 2005, at 10:11 am, Patrick Lauer wrote:
On Wed, 2005-05-11 at 23:58 +0100, Stroller wrote:
On May 11, 2005, at 8:10 pm, Ciaran McCreesh wrote:
* Unique ID strings for packages, zynot style. Messy as hell though,
DEPEND="foo/bar {12379812AD7382164BD87678652438FC65E43A2}" doesn't
have
the same kind of ring to it...
Maybe I'm just a messy person, but I really like this.
So does Microsoft. The registry has many entries where 128bit (?)
object-IDs are used. Very interesting to debug.
I'm going to ignore that. This thread started because the current
category/name naming convention causes interesting conditions. I
appreciate that generally Microsoft Are Not Our Favourite Software
Company, but giving them as an example doesn't inherently make unique
IDs bad, and 128-bit ones are not necessary in this case.
Also, before I start, I'd like to say that I know I'm not qualified to
advocate this as a serious suggestion for adoption by Gentoo, so I'm
just explaining _why I like it_.
It prevents upstream naming collisions
But reduces readability for humans to zero. We don't want that.
Humans are used to dealing with indexes - we remember phone numbers
easily, and if we're looking up several things in a large volume, then
we're used to using bookmarks or noting down page numbers. A six figure
decimal packageID allows for a million packages in the Portage tree
(and I'm assuming versions will be separate, anyway), a five figure hex
ID would allow far more.
Yes, arbitrary unique IDs would require an index tool to access ebuild
name / category data, but surely there is little choice if
naming-collisions are to be avoided and multiple categories are
desired? Surely any human-focused naming convention will cause
collisions and introduce potential for confusion? The current
categories divide collisions into separate spaces, but they don't solve
the problem of foo-player being eligible for both the media-CDplayers
and audio-mp3rippers categories.
At least you haven't tried to optimize it all by using XML ...
but the rest of us will use
`esearch -o "%p\n" "" | grep -e category -e keyword`.
*head explodes*
No.
That's the first time I used that command, but it only took me two
minutes to look up & test. Since a dedicated index tool would clearly
be required, I'm sure it would have better & more useful syntax.
Currently I assume that Mr Harring searches for all the applications in
a category by typing `ls -d /usr/portage/app-category/*` - wouldn't it
be easier to use `esearch --category country`. Not only would it list
them all, but multiple categories per package would also allow those to
be shown that might debatably be categorised as "western".
...It might make portage more resilient to one kind of problem,
but forget debugging then.
Do we have 65000 unique packages in the tree? Would a four figure hex
"part number" be that hard to remember when you're debugging package
names?
Again: I know I'm not qualified to advocate this as a serious
suggestion for adoption by Gentoo, so I'm just explaining _why I like
it_.
Stroller.
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] Wireless driver / firmware ebuilds & wireless-tools
Hi, I thought about filing another bug about this, but decided I'd rather whine about it in public to get a better airing / flaming / understanding of the issues. Using a wireless network card under linux may require various components: - the hardware driver itself - a firmware to be uploaded to the card via hotplug - hotplug - as I understand it: wireless-tools to actually configure the SSID, WEP key &c of the wireless network to be connected to. Is my understanding of the last point incorrect? Because it seems to me there's little point in emerging the ebuild for a wireless network card unless it's going to be connected to a wireless network, and in that case the least thing that's going to need setting is the SSID & IP address. Prism54 is the name of one such driver, and because it is being incorporated into the main kernel tree there exists more than one ebuild for it - one which includes the hardware driver module itself, and one for one for users of the latest kernels who only require the firmware. These two ebuilds take a different approach to wireless-tools - one requires it as a depend, the other does not: $ emerge -pv prism54 These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild N] sys-apps/hotplug-20040923 43 kB [ebuild N] net-wireless/prism54-firmware-1.0.4.3 91 kB [ebuild N] net-wireless/wireless-tools-27 +nls 0 kB [ebuild N] net-wireless/prism54-20050125 -pcmcia 74 kB Total size of downloads: 210 kB $ emerge -pv prism54-firmware These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild N] sys-apps/hotplug-20040923 43 kB [ebuild N] net-wireless/prism54-firmware-1.0.4.3 91 kB Total size of downloads: 135 kB $ I filed a bug <http://bugs.gentoo.org/show_bug.cgi?id=87197> about this a few weeks ago, and was told: "The firmware itself does not depend on wireless-tools for operation. DEPEND/RDEPEND/PDEPEND in ebuilds are not for what you might want to use along with the package in question - it is for technical dependencies such as libraries and utilities." Now, as I say, I can see few reasons to install the prism54 firmware & not use wireless-tools - were you to use a Prism54 card in passive-mode as a packet-sniffer then I suppose it's possible, but most users want to `emerge prism54-firmware` and have it "Just Work (tm)". Having been blown out on my bug I took it deeply personally, then shrugged & forgot about it. Forgot about it, that is, until I went to setup the wireless card in a freshly-installed laptop today: $ emerge -pv acx100 These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild N] net-wireless/wireless-tools-27 +nls 0 kB [ebuild N] net-wireless/acx100-0.2.0_pre8-r5 -pcmcia 275 kB Total size of downloads: 275 kB $ It seems to me that I could now file a bug about acx100 saying that it "incorrectly depends upon wireless-tools" but - unless I'm misunderstanding something pertinent - I still think this is the wrong behaviour. Whether I'm installing a prism54 or an acx100 card in my machine, I'm still going to need to iwconfig them to the right wireless network. The ebuild for the Ralink cards seems to feel the same way: $ emerge -pv rt2500 These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild N] net-wireless/wireless-tools-27 +nls 0 kB [ebuild N] net-wireless/rt2500-1.1.0_beta2-r1 +qt 286 kB Total size of downloads: 286 kB $ So, anyway, I don't intend for this posting to be a criticism of brix for blowing me out on my bug, I just want to understand better. Can anyone tell me if there's a logical reason for wireless-tools to be treated differently by these 4 packages? If you "might want to use" wireless-tools in almost every circumstance with the prism54-firmware & this isn't covered by DEPEND/RDEPEND/PDEPEND, can we have a new variable "YOU_MIGHT_WANT_TO_USE_DEPEND", please? Stroller. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Wireless driver / firmware ebuilds & wireless-tools
On May 21, 2005, at 6:25 am, Doug Goldstein wrote: Stroller wrote: Hi, . far to long. Yeah, sorry... I've always been pedantic. It's a real hard habit to shift. In summary and simple conclusion, yes you are wrong. So that makes 2 out of the 4 or 5 active Mobile herd devs who say you're wrong. Sorry again. Maybe I didn't make myself clear. I didn't mean to say in my posting "I'm right", but rather I intended to ask: Surely a user who emerges prism54-firmware will depend upon wireless-tools? "The firmware itself does not depend on wireless-tools for operation. DEPEND/RDEPEND/PDEPEND in ebuilds are not for what you might want to use along with the package in question - it is for technical dependencies such as libraries and utilities." Ok... so you're saying that the way to resolve this is to have a variable called USER_WILL_DEPEND or similar? The firmware, which in 2 of these cases are in seperate packages, do not depend on wireless-tools. Y'see I'm just not getting why not. A user can install Gentoo, compile the prism54 drivers in to his kernel, emerge the prism54-firmware ebuild and not have wireless-tools. Yet having emerged the prism54-firmware the user has indicated to Portage that, yes, indeed, he intends upon using a wireless network card. As I understand it, the firmware can be uploaded to a wireless card without the wireless-tools, but nothing useful can be done with either the wireless card or the firmware without it. Are you telling me this understanding is wrong? The distinction between driver & firmware kinda dawned on me whilst writing my original email, but I don't the practical implications. The user needs wireless-tools in either case, right? Is it the case instead that using DEPEND, RDEPEND or PDEPEND would break something else if used to indicate the user's need? Hence a variable called USER_WILL_DEPEND would be more suitable? This is just melting my head, because I just don't see what I've got wrong here - both you & brix have told me so, so you must be right. Could you please explain more slowly for me? And for a last example which I just thought of... ndiswrapper acts the sameway. Considering the Windows drivers are more of a "firmware" and ndiswrapper is the driver. Mostly for ideological reasons I tend to ignore NDISwrapper, but I see that emerging it pulls in wireless-tools. This seems correct and sensible to me - by emerging NDISwrapper the user has indicated that he intends on installing a wireless card (right?), so the ebuild provides him with the tools he will need to set its SSID & WEP key. Stroller. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Wireless driver / firmware ebuilds & wireless-tools
On May 21, 2005, at 8:47 am, Roy Marples wrote: On Sat, 2005-05-21 at 05:06 +0100, Stroller wrote: - as I understand it: wireless-tools to actually configure the SSID, WEP key wpa_supplicant can do this as well which makes wireless-tools optional Ah, expletive! Please excuse my last email, then, which went from my outbox just a few seconds ago. What's the difference between wpa_supplicant & wireless-tools, then? Could ipw2200 (theoretically, as a virtual, or at some point in the future) depend upon wpa_supplicant instead? Stroller. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Wireless driver / firmware ebuilds & wireless-tools
On May 23, 2005, at 11:04 am, Roy Marples wrote: On Sat, 2005-05-21 at 09:25 +0100, Stroller wrote: What's the difference between wpa_supplicant & wireless-tools, then? Both do the same job - provide the tools to configure your wireless card. wpa_supplicant is a daemon that runs in the background and when it associates with an AP in your list it applies the pre-defined security settings. Any current wireless security on SOHO boxes is supported. wireless-tools is a set of programs that configure your card per your settings and call it a day. Gentoo baselayout does some rudimentry scanning and AP selection, so it's not that bad. Only WEP security is supported. Thanks to both yourself & Mr Gianelloni for clarification. I'm sorry for the confusion. Sounds like wpa_supplicant is the more sophisticated software - I shall look into it. One minor point: On May 23, 2005, at 7:58 pm, Chris Gianelloni wrote: Surely a user who emerges prism54-firmware will depend upon wireless-tools? ... They could also be setting up their card as an access point or as a sniffer device. I think the access-point will need `iwconfig` (or similar if it's provided by wpa_supplicant) to set the SSID & (optionally) WEP key. That's what I use around here, anyway. I intended to cover the sniffing aspect in an earlier posting - it's a fairly niche usage, and I'd imagine it to be rare that a machine will be dedicated to sniffing for networks & never used to connect to one. But in any case, the functionality contained in wpa_supplicant covers my arguments, and I apologise for not being aware of it. Stroller -- gentoo-dev@gentoo.org mailing list
