[Exherbo-dev] Exherbo Impressions ~ From Installation to Uptime

Sess leycec at gmail.com
Fri Mar 5 04:44:58 GMT 2010


On Fri, Mar 5, 2010 at 01:48, Ciaran McCreesh <
ciaran.mccreesh at googlemail.com> wrote:

> On Thu, 4 Mar 2010 18:38:58 +1300
> Sess <leycec at gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.exherbo.org/pipermail/exherbo-dev/attachments/20100305/e86d1602/attachment-0001.htm>


More information about the Exherbo-dev mailing list