[arch-dev-public] Repository cleanup [current] and [base] --> [core], this weekend!

[Roman Kyrylych]

2007/9/12, Jason Chu <jason at archlinux.org>:
> What are all the steps we'll have to take and what problems will those
> cause?
>
> - Create a new CVS repo for core (or do we just use the current "arch" one?).
>
> - Copy PKGBUILDs from one CVS repo to another (thus losing history).
>
> - Retag the CURRENT and CURRENT64 versions (which aren't necessarily the
> most recently commited versions).
>
> - Update the web db to reflect the new core repo and remove the old current
> repo and point to the proper cvs.archlinux.org urls.
>
> - Delete packages from one repo and add them to the other
> (~/staging/arch/del and ~/staging/extra/add).
>
> - Update and test db scripts to create db-core (and db-core64) and remove
> db-arch (and db-arch64).
>
> - Release a new version of pacman with the new repo paths.
>
> - Tell all users to update their pacman.confs to point to core, not current.
>
> - Update the rsync.conf to sync the core directory and not sync the current
> directory.
>
> - Update viewcvs with the new CVS repo and remove the old one (but there's
> still non-packages in there...).
>
> Is there anything I missed?
>
> When I look at this list there sure seems like a lot that needs doing...
> Can we maybe break it down into stages where things are still backwards
> compatible?

We can modify scripts that create core.db.tar.gz to also create
current.tar.gz and on ftp we can make current symlink to core.
This should provide (temporary) backward compatability without
modification of pacman.conf and new pacman package release.

>
> As much as Aaron is going to hate me for it, I really don't want to do
> anything this weekend if we don't have a complete list of the things that
> need to be done (preferably in what order) to make this transition smooth.
> I want to cause as little problems for current users as we can during this
> transition.
>

-- 
Roman Kyrylych (Роман Кирилич)