On Fri, Mar 5, 2010 at 01:48, Ciaran McCreesh < [email protected]> wrote:
> On Thu, 4 Mar 2010 18:38:58 +1300 > Sess <[email protected]> wrote: > > {*} Stable exheres. There aren't any. Most exheres are known > > unstable and marked as such, or otherwise known stable (...for most > > architectures for most distros) and still marked unstable. > > The whole stable / unstable thing's a Gentooism that doesn't really > work. When we reach a point where we consider stability to be > interesting, we'll probably do something completely different. > Who doesn't consider stability interesting? I do. (Not as much as, say, Debian developers. But I do.) What's the issue with Gentoo's stable/unstable dichotomy? The core idea of marking known working exheres as "stable" and experimental exheres as "unstable" strikes me as fundamentally useful. Is there another way? > {*} "xorg-server" not a hard dependency of X.org-dependent exheres. > > Not a single exheres pulled in "xorg-server". Simply solved, of > > course: "paludis -i xorg-server". Everything works now. (Am I missing > > something?) > > You're missing that those packages don't require an X server. They just > require a few X libraries. It's entirely reasonable to install X clients > on a box that does not itself have an X server. > Yes, of course. But is it reasonable to install a X windowing manager without an X server? (FVWM, in my case.) > > {*} No "nano" installed by default. Now, I encapsulate myself in > > "vim" as much as the next geek. And I still find Exherbo's disclusion > > of "nano" a wee... inhospitable. I doubt including "nano" would > > inflate the staging archive much. This suggests religious reasons. > > Tell me I'm wrong. :} > > There's e4r, if you can't handle the POSIX standard text editor. > It's not about what I can handle. I handle vim; I handle emacs; heck, I handle Eclipse. It's about what the average user can handle. I wasn't aware of "e4r". Looks respectable. Google and the e4r splash message suggest this is an Exherbo-specific patch. Perhaps Exherbo documentation should mention its existence. Installation instructions might be a helpful start... Installation instructions on a Wiki would be a better start. > > {!} No "baselayout-2" or "openrc" exheres. > > Because baselayout-2 is approximately three zillion times more horrible > than baselayout-1. If you like baselayout, use Gentoo. > I like Gentoo. I like Exherbo more. That's why I'm using it. > {*} No "/usr/portage/profile/use.desc" or > > "/usr/portage/profile/use.local.desc" equivalents that I could find. > > I prefer grepping files to grepping "--show-use-descriptions" output > > when maintaining "/etc/paludis/options.conf". > > Use 'cave show' to get descriptions. Option descriptions mostly live in > individual exhereses, not globally, although there is metadata/options/. > Yes, of course. That's not what I'm suggesting. I'm suggesting some mechanism for grepping all uses of some or several options across all exheres: e.g., "cave show --type option qt4". > {*} MYOPTIONS syntax. It looks increasingly like a markup-based > > scripting language: e.g., "[[ number-selected = exactly-one ]]". > > Reinventing the wheel, mayhap? This looks to be a programmatic > > problem. I can't help but feel a programmatic solution might be more > > appropriate. > > Doing it as a function breaks the whole 'upfront configuration' thing, > and makes automated testing a pain in the arse. The syntax we have > covers nearly every use case, and pkg_pretend is there for the rest. > Fair enough, Ciaran. :) > > Tangentially: why the "MY" prefix on "MYOPTIONS"? > > Because it's a lot less likely to bugger up makefiles than OPTIONS. > Sweet. Thanks. (Are we really exporting exheres-specific globals to Makefiles? I'm surprised Makefiles aren't sandboxed, in some fashion.) > {*} "cave." I'm not fond of the name... It's non-descriptive; it's > > non-expressive; it's non-unique. Paludis. Pacman. Apt-get. Great > > names. "cave"? I'd like to know the design impetus behind this one. > > It's Latin. > It's also indistinguishable from a commonplace four-letter English word. > > "dhcpcd." The 5.x.x branch of "dhcpcd" is unstable and significantly > > breaks backward compatibility with the 4.x.x branch. For example: > > passing the "-N" option to dhcpcd 4.x.x prevents dhcpcd from > > overwriting "/etc/ntp.conf"; passing the same option to dhcpcd 5.x.x > > produces the (humorously misspelled) fatal error: dhcpcd: unknown > > otpion 'eth0' Yes. Fatal error. And it doesn't even reference the > > offending option. Thanks, Roy Marple. On my 64-bit AMD machine, > > dhcpcd 5.x.x also tends to enter "unkillable" process states where > > not even "kill -9" is sufficient to kill a zombified dhcpcd process. > > I don't know what the proper Exherbo protocol is here, but marking > > the dhcpcd 4.x.x branch stable for all architectures would probably > > be a healthy start. Emitting a notice concerning backward > > incompatibility at installation time of the dhcpcd 5.x.x branch > > should probably also be helpful. > > Bugs go upstream. If you don't like 5.x, mask it yourself and maintain > 4.x. > I'm not suggesting that I don't like 5.x. I'm suggesting that 5.x significantly breaks backwards compatibility with 4.x. Thus, porting "/etc/conf.d/net" from dhcpcd 4.x to 5.x such that the system still works is non-trivial. > {*} "inquisitio." Still orders of magnitude slower than Gentoo's "eix." > > Ideas why? > > Because it gives correct answers. > I don't recall receiving incorrect answers from "eix", but submit it may have happened. Once. Maybe twice. On the whole, I would happily pay for faster response times with imperceptibly reduced precision. > > {*} Non-free firmware. My discrete Radeon HD4330 video > > card requires non-free firmware, freely available at: > > http://people.freedesktop.org/~agd5f/radeon_ucode/<http://people.freedesktop.org/%7Eagd5f/radeon_ucode/> > <http://people.freedesktop.org/%7Eagd5f/radeon_ucode/>. > > I'd like to see non-free firmware optionally available via some > > repository (if not conflicting with Exherbo policy) or otherwise > > discussed in Exherbo documentation. > > You are welcome to put it in your own repository, and you can have your > own repository listed in ::unavailable-unofficial. > Sweet idea. Exherbo empowers. Thanks for the time, Ciaran; and take care. Humbly yours, Cecil
_______________________________________________ Exherbo-dev mailing list [email protected] http://lists.exherbo.org/mailman/listinfo/exherbo-dev
