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

Martin Baldan martinobal at gmail.com
Tue Dec 26 01:23:33 UTC 2006


On 12/20/06, Michael Homer <gobo-users-dufus at wotfun.com> wrote:


>
> > 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).


I didn't quite understand what you mean here. How do think they could be
aliased and why would that break the filesystem-as-database principle? Can
you elaborate, please?



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.


I've been thinking of this, and I have some vage ideas, but as you may
guess, it's a bit tricky to convey details of user interaction in a such a
static format as e-mail. I mean things like the user hitting tab and the
shell autocompleting, or the user moving the cursor with arrow keys and then
hitting tab and so on. Besides, I must admit I'm not sure whether zsh can do
all this, or whether zsh has to call another program, or a different shell
would be needed (maybe scsh combined with "Commander S" is better suited for
the task, but that's overkill). So, just a few vage points:

_The ugly <B>,<E>,<S> are just to avoid spaces and brackets in package names
themselves. They can be replaced by "(", ")" and space, respectively, in the
shell.

_Automatic indentation should be transparent to the user, in the sense that
it should look like a line break, but not be a line break. The user should
be able to navigate the indented name using just left and right arrow keys.
Hitting tab should take another name to the top position, with the cursor at
the end of the name. When the user hits enter, it should be interpreted by
the shell as usual, and execute the command.

_Sometimes the user tries tab completion, then he sees there are too many
options. So he takes one of the options, the most similar to what he wants,
deletes part of it, replaces it with the desired text and hits tab again.
For this to work without breaking the S-expression syntax, some restrictions
may apply. For instance, the user should't be allowed to delete a "(" or a
")". Instead, he should be required to delete everything between them, and
then delete the "()" pair. If some keywords were replaced (such as "patched"
instead of "p") a single backspace should delete the whole keyword, as if it
were a single character. If they were added (such as "with patches"), they
shouldn't be deletable, but they should delete automatically when the main
keyword is deleted. Maybe a different color for keywords would help the user
to get used to this behavior.


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
>

For the moment it's all speculation. I don't know of any linux distro doing
this, and I'm far from being able to do it by myself. I don't want to sound
like I'm trying to tell Gobo devs how to manage the distro. Sharing and
debugging some ideas, that's all.

That said, I would add a minor number to Gobolinux itself. Octal would be
ok, but I'd prefer hex, because it's also a power of two, and far less
digit-hungry. The minor number needen't be displayed it Gobo sites or
release announcements. It would be just for the system to read. It would
allow Gobo devs to  frequently rename packages with very long names, so that
they take on a shorter one. Each time they rename a group of packages, they
would have to increase the minor distro number. When a user connects to the
Gobo repos, his system knows whether the installed distro number is lower
than the latest one, so it would look up the package names in a legacy names
table. This would avoid all kinds of name clashes that may otherwise happen
when packages are renamed.

For instance, the "official" patched version of Firefox in Gobolinux
020.1woudn't be the same as the "official" patched version in
Gobolinux
020.2. Let's say there have been 83 official versions of Firefox, including
the one in Gobolinux 020.2. Then, in 020.2, the former official version of
Firefox has been renamed:

From: <B>m<S><N>[1]Firefox-2.0[1]<E>
To:   <B>v<S>82<S><B>m<S><N>[1]Firefox-2.0[1]<E><E>

And that's how users see its name, as long as their system is updated to
Gobo 020.2. On the other hand, users whose system is 020.1 would still see
the the old Firefox name, and they would see the offcial (in Gobo 020.2)
version of Firefox with a different name, that is:

Instead of: <B>m<S><N>[1]Firefox-2.0[1]<E>
They see: <B>v<S>83<S><B>m<S><N>[1]Firefox-2.0[1]<E><E>

Of course, It's crucial that dependency names and, in general, any reference
to package names in scripts can be translated in this way by the local
system.

This would allow a really smooth upgrading of the system. That is, the user
decides when to update his Gobo version number. In the meantime, he can
connect to the repos and install packages, and the local system translates
the package names to avoid name clashes. A system reinstallation would still
be needed (probably) for things like a massive change in the filesystem, but
upgrading because of package renamings would be optional.

As you may guess, the Gobo branches I have in mind would work in a similar
way, all branches sharing pool of packages, each branch calling each package
in a different way, longer or shorter, depending on how interesting this
package is for this branch. This is an additional level of complexity, since
each branch would also have its version number, just like the main branch,
to allow package renamings inside the branch, as described above. Migrating
from branch to branch would be analogous to upgrading (or downgrading) the
system: just a matter of package renaming.

-Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.gobolinux.org/pipermail/gobolinux-users/attachments/20061226/5c2fda15/attachment-0001.htm 


More information about the gobolinux-users mailing list