Please consider moving repo of SlackBuilds.org to Github

sycamorex · 01-11-2014, 03:16 AM

Quote:

Originally Posted by willysr

Here are some common problems we found:
Not following the guideline and latest template are the most common thing
People often used their original submission instead of the modified script in our repository
Putting too many unnecessary information on the README and slack-desc
Wrong md5checksums

We don't want to spam your inbox with other people's problem, so we reply it personally for each submission if we think it's necessary. Otherwise we will just clean it up for you, but see second point above.

OK, thank you.

gargamel · 01-12-2014, 05:36 AM

Quote:

Originally Posted by astrogeek

I second that! +1! And thanks as always to the SBo maintainers!

I am not actually a github fanboy anyway. I find navigation on unfamiliar projects, and particularly getting to needed info somewhat difficult and tedious (but also maybe due to my own ancient habits).

+1 for both points:

1. Don't fix SBo, when it is not broken.
2. Github is great for developers, but the standard end-user frontend is anything but user-friendly. Navigating SBo is much simpler, online or with sbopkg (great tool, BTW!).

gargamel

gargamel · 01-12-2014, 05:51 AM

Quote:

Originally Posted by willysr

This will make packages bloated just like other distribution, which is something we tried to avoid
We list the hard dependency in the .info file and list the known optional dependencies in the README. The decision is left for the user to pick

Hmm, yes, please never deviate from this philosophy, which is a major aspect of the philosophy the drives the whole Slackware ecosystem. But still:

Listing dependencies in a README file or listing them in a queue file or something similar wouldn't make that much of a difference, would it?

The information needs to be maintained, anyway. Just putting it into a README file makes it harder to process in scripts etc., however. But I am not a maintainer, so I may not see all the implications.

But also: No, I am not requesting Portage or similar for Slackware.

gargamel

willysr · 01-12-2014, 11:00 AM

Some maintainer have put the optional deps on the README already, but not all of them tracked the optional dependency since it may lead to other package to be installed, configured, etc
Normally people put the minimum dependency for packages to work with and spesify more optional dependency whenever they found it useful for other, since normally dependencies gets more and more on each new major release

ReaperX7 · 01-12-2014, 02:47 PM

It might be good to list optional dependencies, but only the most commonly used and defaulting to a Boolean setting of "no".

dugan · 01-12-2014, 03:37 PM

Quote:

Originally Posted by gargamel

2. Github is great for developers, but the standard end-user frontend is anything but user-friendly. Navigating SBo is much simpler, online or with sbopkg (great tool, BTW!).

This seems to be based on a misreading of the original post. The proposal isn't to replace the SlackBuilds.org website or sbopkg with GitHub. The proposal is to move the git://slackbuilds.org/slackbuilds repository to GitHub. That's the git repository that's pointed to by the "Access to the repository is available via: ftp git cgit http rsync" link that you see on every SlackBuild page.

willysr · 01-12-2014, 06:52 PM

Quote:

Originally Posted by ReaperX7

It might be good to list optional dependencies, but only the most commonly used and defaulting to a Boolean setting of "no".

listing and taking care lots of optional dependencies can be a nightmare for maintainer

willysr · 01-12-2014, 06:58 PM

Quote:

Originally Posted by dugan

This seems to be based on a misreading of the original post. The proposal isn't to replace the SlackBuilds.org website or sbopkg with GitHub. The proposal is to move the git://slackbuilds.org/slackbuilds repository to GitHub. That's the git repository that's pointed to by the "Access to the repository is available via: ftp git cgit http rsync" link that you see on every SlackBuild page.

IMO, i don't see much difference
it's the same GIT repository where you can clone (or fork)
the difference maybe just inability to pull request + submit issues, which Ponce has answered before

we do have slackbuilds-users mailing list and #slackbuilds channel which are perfect way to submit issues.
if you have your own slackbuilds repository and want to ask for pull request, then it's *still* possible (just like Ponce said)

But, moving to github will lose some script checking which was conducted when you submit to SBo and many other thing happening in the backend

gargamel · 01-12-2014, 09:05 PM

Quote:

Originally Posted by dugan

This seems to be based on a misreading of the original post. The proposal isn't to replace the SlackBuilds.org website or sbopkg with GitHub. The proposal is to move the git://slackbuilds.org/slackbuilds repository to GitHub. That's the git repository that's pointed to by the "Access to the repository is available via: ftp git cgit http rsync" link that you see on every SlackBuild page.

You are right, thanks for the clarification!

gargamel

irgunII · 01-13-2014, 07:23 AM

I hate that 'git' stuff/sites with a passion. It's not 'user friendly' (meaning when someone points me there for something I can't make heads or tails of where I'm at, what I'm looking at or where to find it, etc)...it's not easy to figure out, at least for me.

allend · 01-13-2014, 08:08 AM

Quote:

I hate that 'git' stuff/sites with a passion. It's not 'user friendly' (meaning when someone points me there for something I can't make heads or tails of where I'm at, what I'm looking at or where to find it, etc)...it's not easy to figure out, at least for me.

Perhaps you would like "Git for Ages 4 and Up". http://www.youtube.com/watch?v=1ffBJ4sVUb4

granth · 01-13-2014, 05:13 PM

Quote:

Originally Posted by willysr

This will make packages bloated just like other distribution, which is something we tried to avoid
We list the hard dependency in the .info file and list the known optional dependencies in the README. The decision is left for the user to pick

I like to keep things simple, and I also enjoy having granular control over my compiles. However, having to check two different files for dependency information, then tailor a queue file is a tedious task. If the optional dependency information was included in official queue files, but remained disabled by default, it would make life easier for most users.

granth · 01-13-2014, 05:22 PM

Quote:

Originally Posted by dugan

This is pretty much what Portage is. You should try Gentoo.

I've tried Gentoo, but I'm not a fan. I don't feel the need to recompile the entire system.

granth · 01-13-2014, 05:34 PM

Quote:

Originally Posted by ponce

with the new sbopkg, Chess added a tool named sqg (you can find it in /usr/doc/sbopkg-0.37.0/contrib/sqg): the first thing I do on my installs is sync sbopkg making it download the repository, copy sqg to /usr/local/sbin/sqg, modify lines 47 and 48 with the data of the repository I'm using sbopkg with, and launch it with the -a option

Code:

sqg -a

and when it finishes I have all the queuefiles based on the selected repository in /var/lib/sbopkg/queues! \o/
then I add the optional dependencies I need or the necessary switches, parsing the README files, to the queuefiles it generates.

This is a great time-saver utility. Thanks for the tip!

Qury · 01-14-2014, 05:12 AM

Do you guys know if there are any plans to add support for multiple build jobs?
Or are there any environment variables, etc.. that can can be used to take advantage of the multiple cores?