[squeak-dev] Re: Packages, Packages, Packages
siguctua at gmail.com
Sun Dec 13 07:45:19 UTC 2009
2009/12/13 Andreas Raab <andreas.raab at gmx.de>:
> 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
>>> install or any other scripts. Yes, at some point there are scripts
>>> in the installation, but I don't need to execute a shell script *before*
>>> 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
> 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
> 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.
Personally, i don't see the uttermost need of having dependency
information on server.
Code, that runs in specific environment, where you want to install a
project is the place where you can
do dependency analysis 100% correctly, and this is why the code there
can and should be run.
What is the purpose of having it on server side? Display nice web page?
Cmon.. you just need to click and load that project. Nothing else.
>> 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
> 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.
>>> Five years from now, you will not be able to analyze the package
>>> configurations you created today. Because *something* will have changed
>>> 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.
>>> Perhaps so, but Metacello feels bloated. It just doesn't feel right to
>>> 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
> - Andreas
Igor Stasenko AKA sig.
More information about the Squeak-dev