Greg A. Woods; Planix, Inc. wrote:
>
> On 15-Dec-2008, at 2:05 PM, Keith Hodges wrote:
>> Now then lets not get into an argument. I never said that they HAVE to,
>> I said that they CAN.
>
> :-) Indeed.
>
> However with the current state of affairs it would seem that if you
> don't build your own PU then you can't have a stable and usable set of
> packages from which to build your working images with. At my level
> I'm not even sure how I switch from one PU to another, let alone how I
> might build my own whole PU! Even calling it a "universe" makes it
> far too daunting for end users to consider rolling their own. "What,
> I have to create a whole universe!?!?!?" :-)
You are preaching to the converted here, I got so frustrated with
Package Universes, I re-implemented the whole thing in a weekend, and
felt a lot better for it.
The result of that work is Sake/Packages, ok it steals data from
Universes, but it is a whole different animal.
>> Squeak has been without an effective packages solution for so long this
>> has become a big deal.
> I would say the main part of the problem is that there is this "new"
> thing called the Package Universes tool
Its not that new, its been around for a couple of years at least. That's
why I figured it had had its day.
> but it really wasn't needed in the first place -- it was a quick blast
> at an attempt to solve some perceived problems without proper
> consideration of how those problems could be solved with existing
> tools and without proper consideration of the effects such a new tool
> could have on the the thing called "Squeak" and the community that
> uses it. As such it turns out to be totally un-maintainable and useless.
Again, thats why I implemented Sake/Packages.
However what is less clear is how bidirectional integration between
SqueakMap and Sake/Packages would be achieved.
> Unfortunately it is installed as a great big button in the default
> release and everyone is seemingly told to use it to get stuff they want.
I am working on a release of 3.10.2 that is specifically designed for
building things from. I took that button away.
> I really think SqueakMap with dependencies would be the right fix. At
> least with SqueakMap I can filter out stuff that hasn't been "blessed"
> by its maintainer(s) to work on my current release and that really
> just leaves the dependencies and conflicts problems. I think end
> users could pretty much live with SqueakMap if the default filters
> were set to only show stable packages for the release being run, and
> if the dependency and conflict handling problems were solved.
>
> Personally if I were in any way responsible for the Squeak 3.10.2
> release I'd be removing the Package Universe button from the image and
> pushing out a new release and update stream _yesterday_.
or just fixing the universe? Its the 3.10 release folks that are
suggesting a czar.
>> Lets pick an example: Magma:
>>
>> Magma has 3 installations. Magma client, Magma server, and Magma tester
>> Magma should work in 3.7, 3.8, 3.9, 3.10 , and 3.11(to be), and Pharo
>> (to be), thats 18 different definitions in 6 universes.
>>
>> So when I fix a bug in magma do I have to contact 6 different czars?
> With the Package Universes way of doing things, IIUC, yes, you really
> must. Someone has to take responsibility to bless new packages in
> each release.
>
> Package Universes are the logical equivalent to the pkgsrc/ports
> systems in the BSD Unix world. Pkgsrc is effectively a set of build
> and install rules that end users can use to obtain specific versions
> of packages that have been tested and ported to the OS release they
> are using. For example in NetBSD pkgsrc the currently "blessed"
> version of Squeak is still 3.9-final-7067 and it is expected to work
> on all currently supported releases of NetBSD on any supported
> hardware platform. If/when someone ports and tests a newer Squeak
> release to NetBSD _and_ submits an update to the pkgsrc/lang/squeak
> module then NetBSD users of Squeak will be able to upgrade. Until
> that time though only the adventuresome who know how to port and test
> software from scratch will try any newer release of Squeak on NetBSD.
> This process works for over 7,000 packages that have been ported and
> tested to work on NetBSD (and a similar amount for FreeBSD "ports").
> End users can pick and choose from any or all of those 7,000 packages
> and have reasonable expectations that they will all install and
> actually work.
I have never got a linux, or bsd installation tool to work for me. I am
gifted, I can break anything!
>> With Sake/Packages I can theoretically manage the package definitions
>> for all 18 in one single image. When a new version of Magma is released
>> it takes less than 1 minute to update the specific definitions for all 8
>> images. The non-specific 'beta' definitions may simply track "latest"
>> automatically.
>
> Really? I'm not sure how that works. Can you really use one image to
> test loading into at least 6 separate images?
I said that I can update the definitions for the packages in all images
in one place.
Testing is another ball game. The developer of Magma tests it in one
image, and I use it in another, thats 2. Soon we will have an
auto-building capability that will offer more coverage.
> Can you run unit tests from one image in 6 other images?
Magma probably can, since its test suite involves multi-image setups.
> With SqueakMap, IIUC, you can immediately say which releases you or
> your beta testers have tested your new packages against. As an
> unaffiliated user I can choose to turn off the release filter in my
> SqueakMap interface and see your new version and try it out even if it
> hasn't been tested on the release I'm using. At least then I know I'm
> entering new territory on my own.
Keith
Locked
signature.asc (267 bytes)