[TFNR][REPORT]Where are we?!

goran.krampe at bluefish.se goran.krampe at bluefish.se
Tue Nov 25 09:06:46 UTC 2003


"Lex Spoon" <lex at cc.gatech.edu> wrote:
> goran.krampe at bluefish.se wrote:
> > If you look at Debian (or any other distro btw) they don't have such a
> > mechanism. Each package is in a file on its own. And 99% of all the
> > packages I install in Debian are installed using:
> > 
> > 	apt-get install <packagename>
> > 
> > Which resolves dependencies, downloads all needed package files and
> > unpacks/install them etc. 
> 
> This is 99% true.  Even though people mostly use apt-get, they can still
> install individual packages and get the dependencies chacked.  Both
> Debian and RedHat packages know their own dependency information.  When

I am fully aware of that and I still think the scheme I have proposed is
better. :)

BUT...

I have also repeatedly said that sure, if someone wants to put a
"default" configuration into the package (thus of course loosing one
point of my scheme - namely the fact that you can change the
configuration without having to do a new release) or perhaps even better
- if someone wants to bundle a config + the package itself into a SAR to
send somewhere (hey, that is of course much better) - then fine - DO IT.

Let me repeat that without so many parentheses:

Easiest "solution" is to take a package release and one or more of the
configs attached to it on SM and put them all into a SAR. And then send
that SAR to whoever you like.

Then you have it in one file. Of course, the configs aren't very
interesting to look at without having an SM map around - and if you have
that, then you alread have the configs available there too - so I still
fail to see the point of course.

But you can do it.

And yeah, the configs in that SAR will of course easily go stale - since
they are just a snapshot - the originals on SM can still change.

> you try to load a bare package, the system will check these
> dependencies, and if there is a problem it will tell you specifically
> what packages you need to add, remove, or upgrade.
> 
> We don't have to do it the same way in Squeak, but experience shows that
> it does seem to work out okay.
> 
> -Lex

No, the RPM mess in RH causes people quite a lot of pain IMHO. And why?
I am guessing it is because there isn't a coherent map of it all, so you
can't "figure it out" before pulling RPMs home. So you end up
downloading a RPM, trying to install, oops - downloading 3 more RPMS,
trying to install - oops, trying to find some weird RPM you never heard
of - can't find it. Etc.

In Debian there is a coherent map so the above problem seldom appears.

Sure, they still embed the configs inside the packages and allow messy
boolean algebra for the dependency info (probably making dependency
resolution pretty complex) - so there is still only ONE rule for it
(compared to multiple configs), and only the package maintainer can
change it (since it is inside the package release), and a change to it
it will result in a forced new release causing cascades.

And finally (which people seems to forget) if we are just going to
duplicate RPM/Deb then we will have to use a SINGLE package format and
thus drop the fact that SM today is package format agnostic.

With SM2.x all Squeaks will have the map available - even a Squeak
delivered on a CD without a net connection since we can easily put the
map + the packages on the CD.

So let me ask you:

In which scenario would I need to have the dependency information
embedded in the package file?
I assume it must be when I have no map at hand OR the package isn't on
SM.

Since I fail to see why a Squeak wouldn't have the map at hand - then
the only interesting case is when the package isn't on SM.

Future SM versions is planned to allow "sub servers" on companies, or
even privately meaning that I can have my local packages non visible
outside my laptop - or a company can have local packages not visible on
the Internet.

So then the only scenario left (I might be missing something of course)
is when I have a private package that I want to "send" to someone
without access to the sub server it is on.

And by know it seems to me we are down to a pretty rare scenario, but
still - make the SAR I spoke about (release+configs). Since the configs
have a versionField you can at least know if they are stale.

regards, Göran



More information about the Squeak-dev mailing list