[gobolinux-users] Proposal: Whitebox programs and a flexible naming policy for Gobolinux packages

Michael Homer gobo-users-dufus at wotfun.com
Wed Dec 20 05:03:34 UTC 2006

On 12/20/06, Martin Baldan <martinobal at gmail.com> wrote:
> Hi, Michael.
> I have to add more details about practical implementation, such as a policy
> for patch names and Gobo branches (I still haven't touched this topic). The
> problem is that, as one gets more specific with details, it becomes trickier
> and it's more likely that some of those details have to be changed later on.
> The article was meant to lay a naming foundation on top of which to make
> further naming proposals. If there are problems with this foundation, it's
> best to adress them first.
> By now, I'll try to give some quick hints of what I have in mind:
> 1) indeed some hideously long names are shown in the article. I consider
> this a feature: you can build very long, intrincated names from simpler
> ones, without ever running into "syntax hell", so to speak, that is, without
> the risk of name clashes. Those long names are meant to be provisional, only
> used while different combinations of patches are being tested. In a sense,
> they can be deemed as the equivalent of lambda functions, that is, new
> anonymous entities that don't deserve a true name as of yet. When and if a
> package is considered good, the long name is dropped and a shorter name is
> adopted.
I see. That makes sense...
> For instance, take Firefox-2.0
> Initially it would be called <B><N>[1]Firefox-2.0[1]<E>
> Then, when Gobo devs learn it is trademarked: <B>t<S><N>[1]Firefox-2.0[1]<E>
>  And its whitebox version: <B>w<S><N>[1]Firefox-2.0[1]<E>
> Then comes the patching and the long, ugly names.
> Finally, let's say a very popular, patched version is adopted as the
> official modified version of Firefox in the Gobolinux main branch, marked by
> "m". I know, I still didn't explain anything about branches, but  I hope the
> point is clear. Its name would be:
> <B>m<S><N>[1]Firefox-2.0[1]<E>
> Or maybe <B>b<S>m<S><N>[1]Firefox-2.0[1]<E> , where "b" is for "branch". I
> still haven't decided, but both options can be accepted as equivalent.
... but that's still pretty ugly. I guess they could actually be
aliased once final versions were completed, so it wouldn't need to be
that bad (at the expense of the filesystem-as-database principle).
> 2) Lisp-like syntax is very easy to parse, so it can be rendered in more
> pleasant ways. There's no need for zsh to directly show users the ugly
> names. In this sense, you can think of them as a kind of XML document. The
> code may look ugly, but it's easy to make it look good to users.
> For instance:
> <B>p<S><B>w<S><N>[1]Firefox-2.0[1]<E><S>patch1<S>patch2<E>
> Could be rendered by zsh as:
> patched
>   whitebox version of
>    Firefox-2.0
> with patches
>   patch1
>   patch2
> I hope the naming proposal sounds less cumbersome after this clarifications.
I agree that s-expressions are easily parsed, and that sort of display
is pretty much perfect for that information. I'm not sure that zsh
would be the one displaying it - when would that come up? My concern
is when you're looking in /Programs - it's going to be a mess.
`RemoveProgram "<B>p<S><B>w<S><N>[1]Firefox-2.0[1]<E><S>patch1<S>patch2<E>"`
is pretty unpleasant too. If RemoveProgram (and the rest) asked for
ambiguity resolution if needed then that wouldn't be necessary though,
so it doesn't have to be much of a drawback.

This is probably the way most consistent with the Gobo principles to
go about it - I guess that you're really aiming towards what you
wanted in the other thread. I'll be interested to see the practical
implementation details and how you envisage it all fitting together.

More information about the gobolinux-users mailing list