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

Ciaran McCreesh ciaran.mccreesh at googlemail.com
Thu Mar 4 12:48:20 GMT 2010

On Thu, 4 Mar 2010 18:38:58 +1300
Sess <leycec at gmail.com> wrote:
> {*} Having to manually add, configure, and sync unavailable
> repositories after unsuccessfully attempting to install exheres from
> those repositories. Repository hell, frankly. These are
> machine-automateable tasks and I'd like to see paludis options to
> this effect. Ideally, I'd like paludis to automatically add stock
> configuration files to "/etc/paludis/repositories/" for unavailable
> repositories on trying to install exheres from those repositories,
> sync those repositories, and re-attempt the exheres installation.
> Doable?

We'll be doing it with R^2 at some point, so you'll just do `cave
resolve repos/foo`. But that's polish, not critical functionality.

> {*} 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.

> {*} Circular dependencies when building "firefox." Yes,
> there were more than one. One loses count. Each involved the "gtk+"
> exheres in incestuous entanglement with "gtk+"-dependent exheres like
> "cairo," "pango," and "gnome."

These are genuine.

> {*} Circular dependency when building "python" with "tk" locally
> enabled.

Again, genuine.

> {*} "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.

> {*} No "lzma-utils" or "lzop" exheres, thus preventing
> usage of those kernel compression schemes. (I'd prefer the kernel
> provide support for "xv". It doesn't, of course.)

lzma is dead.

> {*} 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.

> {!} 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.

{*} 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/.

> Repositories and exheres strewn about the
> "/var/db/paludis/repositories/" subsystem, thus inhibiting grepping.
> That's bad.

There is no legitimate reason to use grep on anything in a repository.
If you want metadata, ask the package mangler for it. Don't try parsing
things by hand.

{*} "Master repositories are not inherited from masters." Why not? How
> are inheritance conflicts with multiple masters handled? (Just
> curious, mostly.)

Because it's easier not to, and because you don't necessarily need your
master's masters. And there are no conflicts because we don't create

> {*} 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.

> Tangentially: why the "MY" prefix on "MYOPTIONS"?

Because it's a lot less likely to bugger up makefiles than OPTIONS.

> {*} Distfile mirroring. We  could bundle distfiles within git
> repositories (...specifically, in
> the "${FILES}" path for the exheres corresponding to those
> distfiles). We could extend this to load balancing of distfile
> mirrors, as well: e.g., via "git push --mirror" or "git-mirror" to
> GitHub-, Gitorious-, and Exherbo-hosted mirror repositories.

Painful, unless you extract all the distfile contents first. But we
still can't do that until git shallow clones suck less.

> {*} "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.

> {*} "bash." "zsh" is moderately more powerful than "bash." Arguably,
> too powerful. Any chance of a "zsh" port for the exheres-0 EAPI? {!}


> "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

> {!} "xinetd." "http://xinetd.org"
> was down as of my installation, thus inducing that exheres (...and
> all exheres dependent on that) to fail with fetch errors. I retrieved
> a copy of the latest source from:
> ftp://mirror.ovh.net/gentoo-distfiles/distfiles/xinetd-2.3.14.tar.gz**
> Can this be added as a fallback, in the event of "http://xinetd.org"
> falling down again?

It's probably on http://distfiles.exherbo.org/.

> {!} "mysql." "mysql-5.1.42.tar.gz" is
> frustratingly unavailable from all listed hosts. I found it odd this
> exheres didn't default to downloading from
> "http://downloads.mysql.com/archive", where MySQL is always reliably
> downloadable. The exheres should be (probably) patched to defer to:
> http://downloads.mysql.com/archives/mysql-5.1/mysql-5.1.42.tar.gz

Send patches.

> {*} "inquisitio." Still orders of magnitude slower than Gentoo's "eix."
> Ideas why?

Because it gives correct answers.

> {*} 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/>.
> 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.

Ciaran McCreesh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.exherbo.org/pipermail/exherbo-dev/attachments/20100304/8595760c/attachment.pgp>

More information about the Exherbo-dev mailing list