[已解决] 对portage仓库的疑问

flyinflash

按照我的理解
1 ebuild先提交到http://bugs.gentoo.org/
2 然后gentoo开发者commit ebuild进portage tree cvs仓库

portage tree目录提供rsync服务，
emerge客户端平时rsync更新portage tree

疑问
一、我上面的理解有没有错误的地方？

二、对于1，ebuild提交到bugs是上传方式的，上传后，它是不是作为静态文件存储在bugs.gentoo.org服务器上？

三、对于2，commit过程，
是开发者从bugs.gentoo.org下载ebuild，然后commit，
还是直接从存放附件文件目录cp过去？

四、就提高运作效率和迸发访问性能而言，
用户提交ebuild，
是直接存为纯文本ebuild静态文件高效，
还是存入数据库（mysql/postgres/...），在必要时，再生成ebuild文件高效？

flyinflash

按照我的理解
1 ebuild先提交到http://bugs.gentoo.org/
2 然后gentoo开发者commit ebuild进portage tree cvs仓库

portage tree目录提供rsync服务，
emerge客户端平时rsync更新portage tree

疑问
一、我上面的理解有没有错误的地方？

二、对于1，ebuild提交到bugs是上传方式的，上传后，它是不是作为静态文件存储在bugs.gentoo.org服务器上？

三、对于2，commit过程，
是开发者从bugs.gentoo.org下载ebuild，然后commit，
还是直接从存放附件文件目录cp过去？

四、就提高运作效率和迸发访问性能而言，
用户提交ebuild，
是直接存为纯文本ebuild静态文件高效，
还是存入数据库（mysql/postgres/...），在必要时，再生成ebuild文件高效？

五、
http://packages.gentoo.org/
和
http://bugs.gentoo.org/
之间的关系是？

flyinflash

貌似
http://packages.gentoo.org/
和
http://bugs.gentoo.org/
不在同一服务器

2. lab ~ # ping packages.gentoo.org
3. PING nuthatch.gentoo.org (140.211.166.163) 56(84) bytes of data.
4. ^C64 bytes from nuthatch.gentoo.osuosl.org (140.211.166.163): icmp_seq=1 ttl=48 time=201 ms
6. --- nuthatch.gentoo.org ping statistics ---
7. 1 packets transmitted, 1 received, 0% packet loss, time 0ms
8. rtt min/avg/max/mdev = 201.722/201.722/201.722/0.000 ms
9. lab ~ # ping bugs.gentoo.org
10. PING hornbill.gentoo.org (85.17.225.93) 56(84) bytes of data.
11. 64 bytes from hornbill.gentoo.org (85.17.225.93): icmp_seq=1 ttl=51 time=291 ms
12. 64 bytes from hornbill.gentoo.org (85.17.225.93): icmp_seq=2 ttl=51 time=292 ms
13. ^C
14. --- hornbill.gentoo.org ping statistics ---
15. 3 packets transmitted, 2 received, 33% packet loss, time 2002ms
16. rtt min/avg/max/mdev = 291.718/291.947/292.176/0.229 ms

复制代码

flyinflash

手误，重复发帖了，请将这个删除

zhllg

1 基本正确
2. 静态文件
3. 下载，commit
4. 静态文件
5. packages是利用脚本从portage tree生成的

flyinflash

一个提供 上传/下载 小文本文件b的 服务器，
1、为了方便上传，提供web界面（django实现）上传；为了省事，也可以在线编写，然后服务器再自动生成静态文件b
2、为了方便下载小文件b，提供增量更新（rsync/svn/git实现）服务
3、为了方便记录多用户动作和版本控制，使用了git/svn来监视小文本文件的存储目录ee

用户通过web界面提交/在线编写提交，b进ee的中间还要添加一个“审核步骤”，那么，“侍审”文件就不能直接通过pysvn模块commit进 提供下载/更新的 仓库目录ee，

不使用svn客户端来提交直接提交b到ee || 不模仿gentoo的ebuild提交作业模式，主要是考虑到
一、对于非开发人员来说，那样太烦琐；
二、中间的审核不好操作。

我的现在想到的是：
如果不使用数据库，那么必须为“待审”文件b建立一个临时目录，还要给修改它，作谁提交、什么时候提交的标记

如果使用数据库，上传或在线提交的，全部进数据库，审后可以commit进ee，再从数据库生成静态文件

我的想法哪个更好？
如果两个都不好，那么，如何设计，让整体动作有效率并且简单？

zhllg

你去看看bugzilla的实现吧
bugs.gentoo.org不过是用bugzilla而已

flyinflash

bugzilla 本质是一个CMS，而且是perl的东西，太复杂，也不符合我的需要。

我将我要将 portage和emerge 运作方式依葫芦画瓢，写个类似的东西时，有人说使用cvs+rsync效率太低，他认为，官方的portage tree应该使用数据库管理，而不是cvs+rsync。

开发者可以通过 web 网页方式维护portage tree（通过网页修改数据库），然后定时生成按类别分割的、压缩的ebuild  list （类似于deb的 http://archive.ubuntu.com/ubuntu ... y-i386/Packages.bz2 ）。emerge 客户端http下载打包压缩的list。

portage 发展了十年，没有改变cvs + rsync，难道是因为，开发者觉得这样更容易维护portage tree？

zhllg

cvs -> git 已经在进行中了

flyinflash

老大还是没有回答一个问题，为啥不用database来管理，而用version control system？
仅仅是因为，version control？