On Wednesday 14 May 2003 08:56, Lex Spoon wrote:
> Jecel Assumpcao Jr <jecel at merlintec.com> wrote:
> > The Debian package format has a richer dependency structure than
> > the Red Hat format.
>
> The parts that are richer don't seem to be what you are talking
> about, though.  I'm sure that if you used DEB's from different
> distributions, then you'd have the same versioning madness that
> happens with RPM's.

You are right - the social differences far outweigh any technical 
differences. I actually did use DEBs from two different distributions 
when I upgraded a working Debian system to Corel Linux.

> Yeah, that's what I was figuring.  But, umm, isn't the user being a
> little optimistic in these cases to pull in these different RPM's? 
> Put another way, does anyone have any trouble if they stick to the
> actual RedHat-created RPM's?

No, that should mostly work. But what if you want to run Squeak and Red 
Hat/Mandrake/Conectiva/etc weren't the ones who packaged it up as a 
.rpm? There will always be interesting stuff not included in the 
popular distributions.

> > With proper inter-module pointers and universal IDs, you eliminate
> > the human factor of reusing a name for slightly different things.
>
> I don't get this at all.  If we could agree on what the
> name+version's were, then that would be the end of it. 

Ok - I am worried about the case where there is no global coordination. 
Perhaps this is overkill...

> The problem
> seems to be that different distributions label the same code with
> different versions or even different names.  Adding an extra lookup
> table doesn't seem to help this fundamental problem.

What I was complaining about was a lack of agreement on what the public 
interface of a module was. Packages from different vendors with the 
same name included the exact same version of the code, but some 
libraries were present in one and not the other. The code included in 
both distributions did not use this library, so some maintainer had the 
bright idea of eliminating it or moving it to another module.

Now gEDA was saying it needed the guile module, but what it should have 
been able to say was that it needed such and such library.

In Squeak, it would be nice to say that an application needs a given 
class and not that it needs a certain module that happens to include 
that class (for now....).

> I guess you are talking about building a sort of virtual
> distribution, where there is a top-level distribution uses packages
> from multiple other distributions?  That doesn't seem very practical
> to me.  In the Linux world, good distributions do a lot of little
> tweaks to the packages to make them work together nicely.  Why should
> it be different in the Squeak world?

I want an object system, not one built from a bunch of text files. Never 
send a person to do a computer's job. If I want object #12423980890 to 
point to object #54234234238254 then I would rather that Squeak take 
care of this in a way that is easy for it. Having it do that by 
embedding a file name like "c:\winnt\system\sqmods\basic\kgr-1.7.49" as 
a pointer so that I can feel that I am in control will only cause 
problems later on.

> If there is a better way to handle dependencies then let's do it, but
> name+version seems to be a fine way to go.
>
> And at any rate, as you say forks are a long way off -- mostly
> everyone is happy with SqueakMap right now.

It is a great start. The 3.3 module system actually did try to address 
my complaints above (with proper export/import declarations for modules 
and other stuff) but I wasn't surprised to see it run into problems as 
it was at once too simple (there were lots of things it couldn't do, 
like replace projects for example) and too complex (many different 
mechanisms that were essentially doing the same thing).

-- Jecel