slackwarecn / repo Goto Github PK

看了一下slackbuilds.org 已经开放SlackBuild 的上传，我想这个月结束之前把SlackBuilds 都上传上去，要不然好容易写的Build 意义也不大。

现在不少脚本都存在一些不规范问题，关于SlackBuilds 的规范可以参考：

1. slackwarecn/extra-cmake-modules
2. slackwarecn-slackbuilds/extra-cmake-modules

以上两个链接必然有一个有效。

1. 这项工作我会在 #1 结束之后进行，请求搭把手
2. 上传过程中不要修改Build 的任何内容，包括脚本、依赖关系、info 文件等。
3. 上传之前务必阅读并理解Guidelines。
4. 上传的SlackBuild 要确保能够成功构建，并且可以正常工作，这很重要。

@perry2008084 @abbycin @cantaosir @nnnewb @jiatongwu

各种不同的编译系统的SlackBuild规范化
举个红烧栗子

• 打包不使用root权限
• 所有SlackBuild脚本的Author写SlackwareCN Community，另起一行写Contributer
• 根据不同的编译系统提供相应的template
• 提供脚本来生成slack-desc/xxx.info/README.md 信息，避免重复复制粘贴
• 如果软件包同时存在中/英简介，使用英文还是中文?
• 是否允许在SlackBuild脚本内主动检查并输出错误信息？比如if [ ! -f xxx-1.0.tar.gz]; then echo 'source code not found' fi
• 使用slackbuilds.org的template脚本风格或者是自己规定脚本风格？

诸如此类

由于现在SlackBuild 越来越多，导致项目显得比较混乱，所以想做单开一个组织存放Build，而创建这个项目用来统一存放Build，这在能方便Build 管理的同时也能有一个简单的Build 审核流程，能够最低限度的控制Build 的质量。

• 建立一套管理脚本
  • 根据参数添加/删除submodule
  • 统一更新所有submodule
• 项目迁移
  • 将现有的项目移动至slackwarecn-slackbuilds
  • 使用管理脚本以submodule 的形式添加到本项目
• SlackBuilds 规范化调整

关于项目的移动：

1. 所有的URL 使用slackwarecn-slackbuilds 而非本项目
2. 项目名称和软件名称相同，例如corosync 的Slackbuild 项目应该命名为corosync 而非corosync-slackbuild

其他问题：

1. SlackBuild 的规范性有待调整。
2. 所有的SlackBuild 都缺少一个README，参见SlackBuild.org 的Guidelines。

我将会在这周末之前完成SlackBuild 的移动，在这之前我将会完成管理脚本的建立。

这个计划大约2 周前准备实施，后来懒癌发作，也没想到Build 增长的这么快，已经到了比较混乱的成都了，感觉还是比较开心的。

@perry2008084 @abbycin @cantaosir @nnnewb @jiatongwu

以后可能彻底不参与了，不知道 @nnnewb 有没有兴趣接一下。