ffmpeg is a classic example of the problem with hosting binaries. Due to copyright issues, a complete ffmpeg binary cannot be hosted or distributed from slackware.com.
There are also issues with optional functionality in programs. If you host a binary for, say qemu-kvm, should it be built with spice support? This can be useful, but not required in many implementations.

I never buy the argument that Slackware should be more like distro xyz. Slackware is Slackware. If you want the features of distro xyz, then go and use it. There are many Slackware spin-offs that strive to deal with perceived problems with user friendliness in Slackware.

we can argue that new users don't know how to use slackpkg to install packages. Slackpkg does not resolve dependencies, however there is detailed dependencies information at SlackBuilds.org. And there are third party tools to automate or semi-automate the whole process.

Excuse me? What I like about SBo is that it aims to become the unified place for SlackBuild scripts. Even Patrick Volkerding recommended it when a new version of Slackware was released.

Why don't _you_ contact the maintainer of E17 SlackBuilds and offer help?

What about time? For the record I save my generated _SBo packages and install them on another machine if I need them. Saves time.

I don't think so. In most cases you just execute the script and it takes care of everything. Sometimes there are different options you can alter. Control.

For the record, the SlackBuilds for these do not build them from scratch.

EDIT: delete double post...

ngc891,
I did not mean to sound harsh with my previous post, simply "That's because writing a slackbuild is cheap" is not that nice to hear.

It is not cheap.

but it's muuuch better than VNC for vms displays, I would have voted yes

Well, it's the same for MPlayer, isn't it? Anyway, I never suggested to host these extra packages on slackware.com. Look at what did AlienBob for the ffmpeg package, it works pretty well. You can have free and non-free packages.

This apply to any kind of packages. Inside or outside Slackware. I don't see the point, you are always able to recompile what you want with the slackbuilds. Providing packages makes a lot of thing easier.

Not sure to whom this is addressed. I never asked to change Slackware, just thought it could be interesting to make some "set" maintained by the community. And that's exactly what Patrick Volkerding thought for Gnome. And it's what I do for E17. And it's what other people do for some packages. If you don't use third-party packages and like to compile everything by yourself, great. But do not say it's useless to have prebuild binaries.

Of course, that's the most prominent slackbuild repo out there.

Well, at first, I didn't know they started from scratch. But the slackbuilds are pretty easy to write and what I see looks good. What kind of help can I offer? My slackbuilds are really easy to find, but as I said, it's not the most important thing for me. I'm maintaining a building infra and compile packages for several arch. That's the big work: getting all the packages built together, tested an published. Writing a new slackbuild for something standard takes me 2-3 minutes.



Exactly, so why not publishing it to help other people? That's the idea.

well, I'm sorry, but I still think it's cheap :-)
In the last 15 years, I wrote hundreds of slackbuilds. Most of them used autotools and were a matter of minutes. Others use standard cmake/python/perl and are not a big deal. Sometimes, you spend more time getting the source package, checking dependencies or writing the description than actual code. Some can be really difficult, that's right, but it's not a majority.
The problem I often get is when the source package build system is deficient. For instance, I almost never found a configure script that honor properly the --docdir directive. It's something I cared about when I wrote eperiodique and elemines, the source packages even contain the slackbuild :-)

If the slackbuild is not cheap, there is maybe something to contribute upstream.

Reading that, why don't you evaulate those scripts you have written, and sumbit some of the more valuable ones (and that are not yet available on SBo) to the SlackBuilds.org project?
People who write SlackBuild scripts as routine and actually use the packages they produce, can add value to the Slackware community sites. Slackware is a small distro, and its community is important.

But still, you should not call other people's work on scripting "cheap". Writing a SlackBuild script may not be a big effort, but after submitting it to SBo you will be expected to keep maintaining it, and interact with the people who use your script(s). That is the hard part, because the public submission creates expectations. We call you a "maintainer" instead of a "submitter" - those two are miles apart.

As for feeding back improvements to upstream developers - I have had bad experiences myself with arrogant assholes who would not consider Slackware as a distro they had to take seriously, so I eventually stopped giving direct feedback and instead look for bugtrackers to register my issues.

And in response to the topic at hand: adding community packages to the Slackware DVD is something which should not be considered, is my opinion.

Eric

1 members found this post helpful.

How about traditional vi?

http://ex-vi.sourceforge.net/

(Just download it and run make -- it works out of the box on Slackware 14.0.)

It has UTF-8 (elvis does not preserve åäöæøðþ et c.) and is smaller than elvis.

(/usr/bin/vim is 2 MB!)

If I'm not mistaken, elvis was chosen for Slackware because vi wasn't available due to licensing. But now vi has been released under a BSD-style license. So what do you think about replacing elvis with it?

/usr/bin/ex (-> vim) and /usr/bin/vi (-> elvis) are just symlinks. So elvis could even be kept and traditional vi included as /usr/bin/ex.

1 members found this post helpful.

I think ex-vi is completely unmaintained since 6-7 years, so world+dog switched to elvis.

It doesn't work here with my terminal.

According to Wikipedia the last release of elvis was 2003-10-21. The last ex-vi is from 2005-03-25.

I just want UTF-8 without vim.

Did you try in XTerm?

"Terminal too wide"

http://elvis.the-little-red-haired-girl.org/
https://github.com/mbert/elvis

Does this help?
http://ex-vi.sourceforge.net/README

I use 800x600 screen resolution so I guess my terminal is small enough.

I thought it was possible to build a redistributable version ...