[squeak-dev] Re: Packages, Packages, Packages

Miguel Cobá miguel.coba at gmail.com
Sun Dec 13 07:45:52 UTC 2009

On Sun, Dec 13, 2009 at 1:22 AM, Andreas Raab <andreas.raab at gmx.de> wrote:
> Miguel Cobá wrote:
>> On Sat, Dec 12, 2009 at 6:56 PM, Andreas Raab <andreas.raab at gmx.de> wrote:
>>> You can parse the RPM spec and do a good bit of analysis without running
>>> the
>>> install or any other scripts. Yes, at some point there are scripts
>>> involved
>>> in the installation, but I don't need to execute a shell script *before*
>>> I
>>> can find out that this package (for example) has a build requirement of
>>> kdebase3-devel. Tell me how I find out anything about a Metacello package
>>> without running it.
>> But that is not true, in fact the repositories are prepared on package
>> upload so that every download is first an update and then an
>> install/upgrade.
> What is not true? That the client doesn't have to run (untrusted) code to
> find out about dependencies? Are you saying that rpm runs code that some joe
> created with the package just to find out about the dependencies? That would
> be news to me.
>> The same can be made in squeak with metacello. On upload time, the
>> server software in charge of the repository can analyze the configuration
>> of the package and generate a new db list with the apropriate meta
>> information.
> And that just goes back to my point about why it's a problem to require
>  untrusted code to run to do that. You are willing to run arbitrary code on
> your server *just* to be able to get to the dependency information? The day
> where someone doesn't like you they'll upload some configuration that nukes
> your server, runs it as a spam bot or whatever. The desire to do server-side
> analysis is precisely why requiring code to express the dependencies is a
> bad idea.

Good point, but not something that couldn't be detected and solved. Maybe in
practice isn't as bad as sounds, but I must agree with you in this. As
I see it,
it only happens if anyone can upload to your official repository. The debian
repository for example, can only be written by official commiters that have
earned their right to push packages to the repositories. If some of them gets
evil and uploads a bad package, the same problem could happen to debian.
Anyway, Debian is running fine at the time.
Of course in an open system as squeak source you can upload code that
will bring an image to a halt with the user knowing (unless they browse the
code in the web interface) it.

>> When a cliente image updates its own lists get this new db and then
>> proceed to
>> solve the dependency graph. When a solution is found, then downloads the
>> appropriate package versions for the package installed and all its
>> dependencies.
> If this actually worked, it would certainly be a major step up from the
> current situation. Because it would mean a client can look at the
> information of the package without running that code. A 3.8 image could read
> that information and tell the user that this package only works in 3.9 or
> later. Which is a major improvement compared to just breaking.

Not that this is something impossible to create or modify in the
metacello package
or even in Bob. They both rely on programatically defining dependencies between
packages. If it shows itself to be needed maybe metacello could change
its format.
Until now, hasn't.

>>> Five years from now, you will not be able to analyze the package
>>> configurations you created today. Because *something* will have changed
>>> and
>>> break that code and as a consequence the entire package.
>> Granted, but also, but it is the same that happens right now with squeak
>> map and
>> squeak source abandoned packages. They no longer work in squeak or
>> pharo. They need modification to run in newer images. That is something
>> that we accept.
> No, "we" don't accept this. You do. Don't speak for others. And this is
> about the meta information, not the actual package contents. If Monticello
> would have taken the same stance it would've never gotten where it is today.
> MC is what it is precisely because it works in *every* Squeak version under
> the sun, and precisely because it has an explicit, declarative model for its
> contents (instead of requiring code to run to produce that model). As a
> consequence, MC is for example capable of parsing traits definitions even in
> systems that don't have traits. That ensures great robustness, and a level
> of interoperability without which it wouldn't have become the SCM of choice
> for Squeak.

Umm, the last time I check the squeak has its own customized version of MC
and it isn't even commiting back to Colin's repository.
And ther is MC1.5 MC2, and several other forks in several squeak forks.
Saying that MC es the MC of choice is as saying that Word is the word
processor of choice just because is found in every machine. This view omits
the incompatibilities between the different versions of them.

>>> Perhaps so, but Metacello feels bloated. It just doesn't feel right to
>>> use
>>> that much code for something that simple.
>> Well, then we'll wait for the next marvelous thing that squeak/smalltalk
>> is going to provide to show the world how dumb they are for using something
>> that works now instead of waiting for the lightweight, fast, non-bloated,
>> well engineered tool you'll have tomorrow, or the next month, or ...
> Aren't you mistaking a few things here? This discussion started with me
> laying out the options of the *existing* solutions and what would need to be
> done to make one of them work. Then you came along selling the shiny new
> stuff.

I am not selling anything. You asked for options for package management systems
and I was amazed by the omision of other tools like Metacello and Bob.
I didn't propose Bob because, as I have already stated, I think that
isn't something
that the plain user can use mainly because of the poor quality of
their documentation.
Metacello has better documentation that even me, in my limited
smalltalk knowledge,
could understand. So I proposed the one I was more familiar with.
If tomorrow Keith or someone else can produce a good tutorial about
using Bob and
that shows that is visible and obvious better than metacello sureley
the day after I will
be recommending it to anyone who asked.
So until Bob can be digerible and understandable by normal users, I will remain
watching the metacello/gofer evolution.

Finally, I want to close this long thread by just asking (I think that
this has already happened)
that you take a look in metacello as an option for package management
for squeak.

Cheers, and thanks for your time and answers
Miguel Cobá

More information about the Squeak-dev mailing list