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