[csw-maintainers] Preview of the new mirror structure available

[James Lee]

On 08/11/09, 10:23:56, Dagobert Michelsen <dam at opencsw.org> wrote regarding 
Re: [csw-maintainers] Preview of the new mirror structure available:

> > opencsw/
> >> experimental/
> >> /
> >> pkgs/ (confined to this directory)
> >> mytest.pkg.gz
> >> sparc/
> >> 5.8/
> >> mytest.pkg.gz (hardlinked to pkgs/mytest.pkg.gz)
> >
> >> testing/
> >> pkgs/
> >> sparc/
> >> 5.8/
> >
> > Too complex and risky to be of any use to *users*.

> Why "too complex"? The users just subscribe to a URL. The structure
> doesn't
> matter as long as they use pkg-get or pkgutil. Apart from that I think
> it easier than the current layout as it puts testing/ closed to
> current/.

In overview, why would *users* want to and why would we do anything
to encourage *users* to subscribe to these?  We should *hide* these
from *users* not distribute via mirrors.

In overview, define the user's profiles and decide what type of package
you think they should be using.

> > distribution/
> >> allcatalogs/
> >> catalog-sparc-5.8-20091002
> >> allpkgs/
> >> mypkg.tar.gz
> >
> > This looks as if your proposal is to formalise the retention of all
> > packages and catalogues (a collection's state).  At first this seems
> > like a good idea but think deeper and you will see that if all
> > catalogues are kept there is no way of knowing which are erroneous,
> > hence they all become useless.  Actually there is a way of knowing
> > because we keep the known good sets as stable releases which is
> > already handled.

> My intentions are different. I want to solve two problems with it:

> 1. There is no official archive for all released package versions

> This is currently handled by 
http://csw.informatik.uni-erlangen.de/oldpkgs/
> .
> While I think that Michael is doing a great job I would prefer that the
> project itself would keep an archive. allpkgs/ is my proposal to handle
> this.

So that intention is the same.

> 2. When you install a package you are forced to upgrade other packages

It's a feature, much thought about.

> The larger customers of ours have own mirrors from where they install.
> However, the smaller installation just subscribe to current/.

That's their mistake.  What are we doing to educate?

> When an
> inexperienced admin just wants to add a package and by error updates
> the catalog there is no way other then to update the dependencies of
> the package to be installed as there is neither an unchanged location
> for scubscription nor the old archived catalog. The freezes are not
> meant as replacement for stable, but as substitute to subscribe to
> in addition to current/.

So whatever state they first install they can continue to use for
additions.  It needs a state for every catalog issued.  It would be
better to designate landmark catalogs and keep just those - oh we do
that already.  Better to make the installer use a named catalogue then
it can use a single bulk archive - or educate inexperienced admins.

> > ** TBD: experimental/ should be filled with the subdirectories from
> >> what is now in testing/.
> >> Subdirectories can be created by each maintainer and for each
> >> folder a subproject
> >> is created in experimental which can be synced to separately.
> >
> >> ** TBD: packages/ can the go from experimental/ to testing/ when no
> >> open issues persist.
> >
> > How will you define "no open issues persist"?

> That the maintainer of the packages doesn't know of any. Currently
> testing/
> contains packages for which the maintainers _know_ that some things
> doesn't
> work but wants to test other things anyway. While it is useful to pkg-
> get
> from the testing-catalog it may not be useful for general testing.
> That's why I want to confine these specific-things-only testing to
> subdirs of experimental/ the maintainers can create at will and use
> whatever
> they think is good but restrict testing/ to packages that are good for
> testing by anyone who wants to help testing and every encountered issue
> is an unknown, actual bug.

I thought that's what testing was, and repeating myself it shouldn't
have a catalogue, or if it does needs a health warning explaining that
it's a sure way to shoot yourself in the foot.

> >> This can be used to drive servers. Only packages proven there can
> >> go to current/. See
> >> http://wiki.opencsw.org/automated-release-process
> >> for details.
> >
> > Here you draw parity to the Debian system.  Previous discussion
> > concluded
> > the levels you show are not correct.
> >
> > "How stuff gets in there", conceptually and practically it doesn't
> > because stable is a modified clone of another state done as an atomic
> > operation.
> >
> > I feel we've lost sight of the aims of the proposal.

> It is a writedown of the discussion of Oslo.

Ah the Oslo Treaty, this must be like the Lisbon Treaty.

> If you actually use
> cswrepo or
> another tool to moves packages there is up to you. If they are
> released atomically as a whole this is independent of the tool to move
> packages between catalogs. The core of the discussion was to formalize
> the moving of packages between catalogs,

We've only had one.

"A catalog" represents a collection that should be integrated, there
should be no concept of isolated additions and movements.  OK that's
what happens but don't formalise it as a concept.

> being the one from current to
> stable just an example. The important point is to have an API for tools
> to deliver to experimental/ and to move from experimental/ to testing/.

Important for what?  Sorry I've lost track of how this is an aim of
providing a service to users.  (How one choses to implement a standard
is one's choice, blah, blah, as agreed above.)

Step 1: define the problem.



James.