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

[Jason Chu]

On Wed, Sep 12, 2007 at 04:31:26PM +0200, Tobias Powalowski wrote:
> Hi
> it's quite a long time ago we had a dev meeting, but i think there were quite 
> some agreement what [core] should be and we should start doing this soon.
> Our next ISOs shouldn't have the big current anymore only ftp and [core].
> 
> [non-free] repository
> we should add a non-free repository with stuff that is not freely 
> distributable, like acroread, sun java, firmware files, flash etc.
> this cleanup would affect [extra] and [current]
> that way we could finally have cds of [extra] too without getting into 
> trouble.
> 
> As Romashka said, these are the types we need to look at:
> 1) those that are not possible to distribute due to prohibition of original 
> package modification, but it does not work without modifications to 
> installation procedure - like vmware 
> 2) those that are not allowed to be redistributed by EULA - like commercial 
> edition of virtualbox 
> 3) those that are not allowed to be sold on a CD, but can be distributed over 
> internet 
> 4) those that are just not Free Software - it's nice to have them splitted if 
> someone wants to have FOSS-only mirror/CD/etc
> 
> 1+2 should be probably moved out of the official repositories, if not already 
> done.
> 3+4 should be ok

-1

I think that we never solved the dependency graph problem with non-free and
I strongly suggest we don't do it.  This can be revisited later.

> [core] repository
> should be like [base] + some extra stuff
> the question is: what is extra stuff?
> imho, it should be everything that is needed for networking
> free kernel network modules
> free wlan stuff
> all supported main filesystems
> 
> suggestion list of packages to add:
> ndiswrapper
> ndiswrapper-utils
> wlan-ng26
> rt2500
> madwifi
> madwifi-utils
> fuse
> ntfs-3g
> iptables
> bcm43xx-fwcutter
> dosfsutils
> ntfsprogs
> kexec-tools
> snarf
> dnsutils
> hdparm
> bridge-utils
> ifenslave
> xinetd
> portmap
> nfsidmap
> nfs-utils
> openssh
> netkit-telnet
> screen
> isdn4k-utils
> capi4k-utils
> vpnc
> openvpn

+1

I haven't really looked over this list, but I'm going to assume that other
people will.  I do like the criteria though.

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?

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.

Jason
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://archlinux.org/pipermail/arch-dev-public/attachments/20070912/38673113/attachment.pgp>