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

[Dagobert Michelsen]

Hi James,

Am 07.11.2009 um 12:45 schrieb James Lee:
> On 05/11/09, 16:16:42, Dagobert Michelsen wrote regarding
> [csw-maintainers] Preview of the new mirror structure available:
>
> Is this a preview or a proposal?

A preview of the proposal ;-)

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

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

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

The larger customers of ours have own mirrors from where they install.
However, the smaller installation just subscribe to current/. 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/.


>> stable/
>> sparc/
>> 5.8/
>> current/
>> sparc/
>> 5.8/
>> pkg.tar.gz (also hardlinked from allpkgs)
>> freeze/
>> current-20091002/
>> README.20091002
>> sparc/
>> 5.8/
>> catalog
>> pkg.tar.gz (hardlinked from allpkgs)
>> 5.9/
>> pkg.tar.gz (symlinked to 5.8, same as in current/)
>
> This misunderstands the WIP nature of the snapshot process.  The  
> freeze
> is on unstable, it's not an entity it's unstable itself that is  
> frozen.

Again: This has nothing to do with freezes needed to build stable.
This whole rework of the layout is the result of the discussion we
had on the founding meeting a year ago. I am just a bit slow...

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

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


Best regards

   -- Dago