[oi-dev] [OpenIndiana-discuss] Installing OpenOffice pkg://openindiana.org/desktop/office/openoffice
Nikola M.
minikola at gmail.com
Fri Sep 26 22:18:17 UTC 2014
On 09/26/14 09:33 PM, Alexander Pyhalov wrote:
>
> Guys, what do you think about this? First of all, why can't we just
> make all incorporations
> empty packages? What harm can it cause?
As I understand, consolidations are there to precisely lock versions of
interdependent packages, that are proved from testing before release, to
work nicely together, forming something that actually work, versus bunch
of disconnected applications where every change of one application can
break functionality of several other in strange ways.
As I understand, consolidations support developing distribution in TEAMS,
where each team tests and works on one consolidation to make it work
independently from another consolidations.
So it have two-fold reasons why it is great way of organizing teams and
testing of 'consolidated' packages. if someone wants to change some package,
one needs to contact maintainer of consolidation and to walk with change
with testing whole consolidation (opposite to affecting whole distribution).
I actually do not understand why having consolidations is a problem.
Simply, if some package needs to be updated in consolidation, it needs
to be tested
and as I understand only consolidation needs to be compiled , not whole
distribution, to test if changes works right. So consolidations seems
like good thing to me.
>
> Currently we have the following incorporations:
>
> pkg:/consolidation/X/X-incorporation at 0.5.11-2014.0.1.0
> I think can be relaxed
>
> pkg:/consolidation/admin/admin-incorporation at 0.5.11-2014.0.1.0
> I think can be relaxed
>
> pkg:/consolidation/cacao/cacao-incorporation at 0.5.11-0.151.1.8
> What is it?
>
> pkg:/consolidation/cde/cde-incorporation at 0.5.11-0.151.1.8
> Perhaps, we could relax it, it seems to be something which is
> going to stuck here, we can't do anything with it.
> Or can we drop it one time?
Perheaps we can form rudimentary TEAMS to test them and to enhance their
presence.
Relaxing consolidations could lead to total breakage of whole distribution
and it undoes any previous testing
and updating every package separately leads to general lowering
distribution quality,
inability to effectively test and debug.
Short answer: we are NOT FreeBSD, if one wants to do it chaotically, it
is not OI/opensolaris way.
And I bet BDSs also have some hierarchy in changes and testing before
release,
and not just "update random package and see what happens".
What happens is random bugs all over the distribution, with no known
working inter dependencies
and unmaintainable mess. (That Hipster without releases and bunch of
consolidations removed or "relaxed" actually is now.
We need Teams for consolidations and teams for testing things.
And clear goal of publishing new /dev after Hipster testing cycle.
>
> pkg:/consolidation/cns/cns-incorporation at 0.5.11-0.151.1.8
> What is it?
>
> pkg:/consolidation/dbtg/dbtg-incorporation at 0.5.11-0.151.1.8
> What is it? Could it be relaxed?
We can Not just "relax" anything before testing updates in it.
True one needs people for it,
but no people are needed to make things started.
Or else, not knowing what consolidations or packages actually do,
leads to total confusion.
I think that also removing other consolidation previously was a big mistake,
also as I already explained.
>
>
> pkg:/consolidation/gfx/gfx-incorporation at 0.5.11-0.151.1.8
> What is it?
>
> pkg:/consolidation/hcts/hcts-incorporation at 0.5.11-0.151.1.8
> It's ddu. Perhaps, we can relax it?
>
> pkg:/consolidation/install/install-incorporation at 0.5.11-2014.0.1.942
> There should be nothing wrong with this one, it's from slim_source.
>
> pkg:/consolidation/jdmk/jdmk-incorporation
> Some java libraries.. Is it closed? I think we can relax it.
>
> pkg:/consolidation/man/man-incorporation
> Perhaps we can just obsolete it? I see nothing depending on it.
>
> pkg:/consolidation/nspg/nspg-incorporation
> driver/network/ce is unlikely to be updated. I think, we can just
> relax it.
>
> pkg:/consolidation/osnet/osnet-incorporation
>
> pkg:/consolidation/sic_team/sic_team-incorporation
> I think, I'll relax it in the nearest future. Or is it better to
> obsolete it?
>
> pkg:/consolidation/solaris_re/solaris_re-incorporation
> I think, we can relax it.
>
> pkg:/consolidation/sunpro/sunpro-incorporation
> I think we can relax it.
>
> pkg:/consolidation/ub_javavm/ub_javavm-incorporation
> We should do something with it. Do I understand correctly, that we
> can't update
> java now? Perhaps, we can relax it?
>
> pkg:/consolidation/vpanels/vpanels-incorporation
> I see that we have vpanels in oi-userland, but they are disabled.
> Perhaps we should enable them? Who knows what is it? Some GUI admin
> tool? Will it work
> on OI and do we need them?
We actually need to use dev docs
Firstly is there somewhere TOTAL backup of opensolaris.org site
(including archive.org), it seems that maintaining opensolais descendent
distribution like OI needs reading at least some docs.
More information about the oi-dev
mailing list