On 02/07/07, Alberto Ruiz <[EMAIL PROTECTED]> wrote:
> 2007/7/2, Shawn Walker <[EMAIL PROTECTED]>:
> > On 02/07/07, Alberto Ruiz <[EMAIL PROTECTED]> wrote:
> >
> > > 2007/7/2, Shawn Walker <[EMAIL PROTECTED]>:
> > > >
> > > > > Seperating package names and package file names is a ghastly
> solution
> > > > > to the problem, if I want to manually download a package called
> > > > > nvidia-drivers, I should be downloading a file called
> > > > > nvidia-drivers.***, not NVDAgraphics.***.
> > > >
> > > > Why does that matter?
> > >
> > > Principle of minimum surprise. If the name is self explanatory, you
> don't
> > > need to figure out what's inside, and you lose less time. Maybe the
> nvidia
> > > thing is not a good example, but just go through the output of pkginfo.
> The
> > > point now is that you are not able to retreive individual packages for
> > > Solaris Express or Solaris 10, so maybe Solaris users are not used to
> the
> > > need of this "self explanatory" thing. At the same time, the version and
> the
> > > architecture on the name are quite useful in lots of cases.
> >
> > There is always going to be some surprise.
>
>
> That doesn't mean that we shouldn't care about surprise at all.
>
> > On debian-based systems I
> > usually found packages using apt-cache search, its very rare that what
> > I actually want can be found by just blindly doing apt-get install. I
> > think the same thing applies here.
>
>
> And then, when you find problems, you will need to handle packages
> individually as files, do you think that it is a good idea to have different
> names in the interface than in the filename? SUNWckr???

What problems? I don't see it as anymore of a problem than the whole
meta-packages or clusters that GNU/Linux distributions often use and
that Solaris uses as well.

> > In addition, the loss of compatibility, I would imagine, is far more
> > important than a minor inconvenience that could be alleviated by
> > better tools.
>
> Indiana is about attracting the users that are not on the platform yet, not
> the ones that are already using it. Compatibility is granted within the
> Solaris world already. I thought that Indiana was exactly about that, taking
> the whole potential of the OpenSolaris technology and expose it easily to a
> new user base. If we get sticked into compatibility issues, then there is no
> point on indiana at all.

That's where I will have to disagree. Solaris has proven that
compatibility issues do not prevent innovation. So far I haven't seen
good reasoning as to why package naming matters so much that it would
prevent innovation necessary to attract users to a platform.

If package naming is really that much of an issue, then I could
probably sit here all day and show you the rather convoluted and
unhelpful names of packages I find on many GNU/Linux distributions
most of the day.

I do not believe that a tool cannot be provided to make it easy to
find and manage software that does not rely solely on arbitrarily
chosen, and not always helpful, package names.

> Indiana should be designed for the long term, as good as possible. Of
> course, compatibility with Solaris should be kept whenever possible, but it
> shouldn't stop meaningful problems.

In the grand scheme of things, I sincerely doubt package names are
going to be what stops adoption of any OpenSolaris based distribution.
I think there are many other things that are far more meaningful in
the long run.

-- 
Shawn Walker, Software and Systems Analyst
[EMAIL PROTECTED] - http://binarycrusader.blogspot.com/

"Beware of bugs in the above code; I have only proved it correct, not
tried it. " --Donald Knuth
_______________________________________________
indiana-discuss mailing list
[email protected]
http://opensolaris.org/mailman/listinfo/indiana-discuss

Reply via email to