Packages, Packages, Packages
Locked
12
12
Re: Re: Packages, Packages, Packages
 
|
On Sun, Dec 13, 2009 at 1:22 AM, Andreas Raab <[hidden email]> wrote:
> Miguel Cobá wrote: >> >> On Sat, Dec 12, 2009 at 6:56 PM, Andreas Raab <[hidden email]> 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á http://miguel.leugim.com.mx |
Re: Re: Packages, Packages, Packages
|
|
In reply to this post by Miguel Cobá
2009/12/13 Miguel Cobá <[hidden email]>:
> On Sat, Dec 12, 2009 at 9:55 PM, David T. Lewis <[hidden email]> wrote: >> On Sat, Dec 12, 2009 at 06:01:55PM -0600, Miguel Cob? wrote: >>> >>> Why would you want to do that. 3.8 is dead, must be dead and should be kill. >>> Let the past behind. Let your childs live their lives and go on. You >>> can't oversee them *your* entire life. Squeak can't remain trying to >>> get backwards compatibility forever. That way squeak will never make the >>> foundation changes that needs. >> >> <rant> >> This is complete utter bullshit. Failing to make a reasonable attempt >> at backward compatibility is lazy and sloppy, nothing more. >> >> Norton's third law of innovation: >> Change is good, stupid is bad. Don't confuse the two. >> </rant> >> >> Ok I feel better now. There are some rather significant forks based on >> Squeak 3.8, and any package management system that fails to accomodate >> this level of variation is in trouble. > > I think that that is the real problem with the solution provided by Keith. > He tries to solve the problem for every fork. As if the forks care > about its changes > being compatible with the project they forked from. > Keith mail after mail tried to convince people that a change must be/should be > loaded in every fork existing and future. Utopia. That don't happens. > If I choose Pharo and the software fix that I made works in pharo, my problem is > solved. I couldn't care less if croquet, etoys, olpc or whatever can use it. > The same they don't give a dime if their changes works on squeak. > As an old discussion in this list pointed, the etoys project long ago > forget squeak. > Nevertheless, squeak is worried if their changes could somehow > break/work/load/compile > in squeak. :( > I think you misunderstanding the Keith's concept. He wanted to provide a common denominator for all existing Squeak forks, to make sure that some basic tools (MC and Installer) working there. But its not gives any guarantees that your packaged code can be installed and work in any of those environments. This is something you need to determine by yourself. Suppose, one developer made project that runs only in Pharo. Then suppose that other developer wants to use it in Cobalt. Now what he can do? This is where it makes difference: if your project loading is based on installer & LPF, one can make attempt to load the project in different environment and see if it loads , or see where it breaks, and then provide own custom installation script(s) , which does the job. But if your project installation meta-info is based on Metacello , Gofer and <put you own favorite tool>, this makes your project highly dependent from tools, which in own turn may require porting to work in different environment. But hey, MC & Installer already ported and ready to work at your disposal. I love new and shiny stuff, but as a software developer i tend to care about potential users of my code. And if my code can be loaded by different forks, this means a broader audience of users of my project. This is what all developers always want, hopefully. And this is why i won't be using a packaging tool which works only in some of the newest & latest squeak environment or its fork. > SqueakMap fell apart when Squeak >> 3.9 came along for this very reason, and we can reasonably expect that >> future variations on Squeak will introduce similar incompatibilities. >> This is a good thing, and our tools do need to be flexible enough to >> support it. > > The only real example of code that works unmodified in newer hosting > environment is > in the zSeries Operating systems from IBM. > They say (I don't know and maybe will never could verify because I > don't have the millions > to buy a mainframe from them) is that you can run software from the > 60s in the 2010 machines > without a single line modified. That is impressive but they charge > accordingly also. > We aren't so well funded nor have a real practical motivation to > verify that every new version > of squeak or pharo can run _every_ old version of _every_ package that > some time ran on > squeak. If someone want to keep using that old software they have two options: > > - remain part of the every day smaller group of users (and what that > implies for bug fixing, etc) > - load the old software in the new images and correct the errors found > > I choose number 2 because is what happend in the nature. The groups > are stronger than the > individuals. > >> >> Dave >> >> >> > > -- Best regards, Igor Stasenko AKA sig. |
Re: Packages, Packages, Packages
|
|
In reply to this post by Miguel Cobá
Miguel Cobá wrote:
>> 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. But they interoperate. That is the key point. MC gets the interoperability from the fact that the MC packages DO NOT call methods on Monticello. If they did (as Metacello does) than the divergence would be absolutely deadly. As a consequence, Metacello is likely to be much more affected by similar divergence if that ever happens (hard to predict). >> 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. Point taken. And yes, I was looking for alternatives. > 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. Indeed. And I'm not done with that. It just turns out that Metacello has weakness alongside with its strengths which shouldn't be a shocking insight ;-) Cheers, - Andreas |
Re: Re: Packages, Packages, Packages
|
|
In reply to this post by Andreas.Raab
On 2009-12-13 08:22, Andreas Raab wrote:
> >> 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. > > Cheers, > - Andreas > > A dependency-resolution engine for Squeak packages. http://www.squeaksource.com/Kabungu Karl |
Re: Re: Packages, Packages, Packages
|
|
Hi!
Karl Ramberg wrote: > Have anyone looked at Kabungu > A dependency-resolution engine for Squeak packages. > http://www.squeaksource.com/Kabungu Yes, I did. When it was written. See my other post soon. regards, Göran |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |