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!?!?!?"  :-)


> 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 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.

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 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_.


> 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.

In the BSD world package maintainers who care about their package on a  
given version of BSD and/or GNU/Linux or Solaris and/or whatever do  
indeed have to contact each pkgsrc/ports/whatever project to let them  
know about the new release and perhaps if they really care they'll  
provide updates to the relevant rules module so that each project can  
more quickly update their packaging system.

Also, in pkgsrc, for example, maintainers might take responsibility  
for a given package or sets of packages and watch for updates from the  
original authors (or even in some cases the pkgsrc maintainer is the  
author).  These maintainers have commit rights to update the relevant  
pkgsrc rules modules.

See www.pkgsrc.org if you're interested in more detail.  There are  
lots of applicable things that can be learned there -- especially  
things about dependency and conflict management.

In the Squeak (and Squeak-related smalltalks) world I think SqueakMap  
could be a better solution for this problem domain in this context,  
provided of course that the dependency tracking and conflict  
management problems are solved.


> 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?  Can you run unit tests  
from one image in 6 other images?

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.

-- 
					Greg A. Woods; Planix, Inc.
					<woods at planix.ca>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20081215/05e79e04/PGP.pgp