Laszlo (Laca) Peter writes:
> It's not a workload issue. We can handle more packages (as long as
> our nightly build completes in 24 hours ;) But it doesn't seem
> logical.
It does seem logical to me: the consolidation with the closest ties to
a given bit of software is the one that delivers it.
We very much want to avoid breaking the software into unnecessary
consolidations, because synchronizing delivery across multiple
consolidations is quite difficult and error prone.
In other words, if your consolidation depends on foo-1.2.3 and you
need to upgrade to foo-1.2.4, things are simple if you can do that as
an atomic 'putback' or 'commit' to a single consolidation's
repository. You (and your customers) are in a world of hurt if you
need to do that to multiple repositories, particularly so if there are
incompatible changes involved.
So, unless there's a clear need for a new consolidation, and complex
_technical_ ties between the packages delivered there, consider this a
"-0" from me. I still need to see a proposal that defines what those
natural groupings are.
> Well, the GNU/UNESCO list has 5300 packages. But I guess you're
> right, there is no reason to exclude packages because they are not
> on the list. How about defining the universe as packages with an
> OSI approved open source license? (Sigh... I need a new project
> name then.)
Yes, there is a reason to exclude them: the ARC approval for /usr/gnu
was for things on that list, and no others.
It has nothing to do with license. It has everything to do with
identifying the scope of the change.
You'll need to write a new ARC case if you really need to change this.
> That's a good point. I don't think it's feasible to go to ARC each
> time we integrate a package into the proposed repository. ARC would
> soon have a huge backlog.
I doubt it. These sound like the most trivial of fast-tracks to
me. Most are probably closed-approved-automatic.
> Perhaps we could have a BFT (blindingly
> fast track) that allocates the name space only.
We already have that process. It's called "automatic approval." No
need to invent a new one. :-/
Rich Teer writes:
> On Thu, 22 Feb 2007, Laszlo (Laca) Peter wrote:
>
> > So the /usr/gnu proposal[1] was approved by PSARC. Obviously, the
> > reason for defining /usr/gnu wasn't theoretical -- it allows moving
> > GNU packages from /usr/sfw to /usr or /usr/gnu and it helps us
>
> I'm nor sure I see the point of exchanging /usr/foo for /usr/bar.
> I mean what problem will /usr/gnu solve that /usr/sfw doesn't?
Several. The primary change is that /usr/gnu is intentionally
"sparse." This means that it contains *ONLY* those things that
conflict with Solaris utilities (e.g., GNU 'ls'). Everything else
goes into good old /usr/bin.
The older /usr/sfw definition was a ghetto for non-Sun software. We
banished stuff there because we didn't want to see users accidentally
depending on things that were less stable than Sun software.
That concept was overturned in PSARC 2005/185 ("Enabling serendipitous
discovery") which said that segregation wasn't good, and that putting
things in /usr/bin was better. However, 2005/185 didn't deal with the
conflict issue.
This new proposal deals with conflicts in two ways: using
'g'-prefixing in /usr/bin, if that's appropriate, plus putting
conflicting things in /usr/gnu under their expected names.
Thus, the user can choose to be more GNUish by doing this:
PATH=/usr/gnu/bin:/usr/bin
> And doesn't that name preclude open source software that doesn't
> use a GNU license?
It has nothing to do with the license.
> I guess what I'm asking is: what is the rationale for /usr/gnu?
See the ARC case:
http://www.opensolaris.org/os/community/arc/caselog/2007/047/
Joerg Schilling writes:
> Dermot McCluskey <[EMAIL PROTECTED]> wrote:
>
> > > Well, the GNU/UNESCO list has 5300 packages.
> >
> > The FSF/UNESCO directory has 5300 packages. Of these,
> > only 365 are GNU packages (last time I counted).
>
> And the FSF/UNESCO directory includes cdrtools e.g. and my ved.
> Both are listed as GPLd but ved ist 100% cddl now and cdrtools
> is 90% CDDL.
It has nothing to do with the license. It has everything to do with
the FSF/UNESCO list.
/usr/gnu is not a dumping ground for arbitrary things that might
happen to be released under GPL.
--
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
opensolaris-discuss mailing list
[email protected]
