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

Michael Homer gobo-users-dufus at wotfun.com
Tue Dec 26 01:48:11 UTC 2006

On 12/26/06, Martin Baldan <martinobal at gmail.com> wrote:
> 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?
What I was getting at is pretty much what you outlined at the bottom,
I think, although I wasn't thinking of system version numbers.
> > 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 vague 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 vague 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.
Either way, it's still too complicated to display to the user. It'd
have to be hidden wherever possible, either by aliasing them or
> _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.
I see. That's not so bad, but I do see two problems: what about when
it's in the middle of a line? Where does the rest of the line go? The
other is that I at least tend to protect my vertical space jealously.
A line with a lot of packages listed in it combines the two of those,
> _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
> >
> 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.
> 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.
That's an interesting concept. I still think it's overly complicated,
but it could be essentially transparent to the user, so that mightn't
be an issue. It would require a lot of maintenance work after the
initial big outlay though, to batch up updates. At least, assuming a
universe where Gobo has the masses of patches you want. Bugfix
releases only wouldn't be so much of a problem.

It is a very interesting concept. Maybe you should have a go at making
a distro to implement it, either forking or going through LFS to build
it up exactly as you envisage.

More information about the gobolinux-users mailing list