[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.
-Michael


More information about the gobolinux-users mailing list