[gobolinux-users] Proposal: Whitebox programs and a flexible naming policy for Gobolinux packages
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>Firefox-2.0<E> , where "b" is for "branch".
> > > 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
> > 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
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