Okay, lots to chew on here.
I have no formal background or education with software development. Several one-class
exposures to some programming languages, but nothing with data structures, etc.
I enrolled in a one semester class in C about 23 years ago. Still have the text book but
have forgotten almost everything. No formal exposure to C++ or Python, both of which I
would like at least nominal skills.
Funny thing is I hated vi 23 years ago and I hate vi today too. :)
Bottom line is that most of my computer skills are from the school of hard knocks. But I
have been attending that school for 30 years. :)
Sounds as though you are offering to host final binary packages for Slackware. Do I
understand correctly?
I have a small personal web site and don't have the bandwidth or capacity to host an
off site build process or hosting binary packages. I considered that particular challenge
when I posted my web page for this project but don't have an answer.
I need to ensure this build process succeeds here locally without issues before moving to
the next step of hosting automatic builds. We are progressing forward, albeit at a slow
pace. There just seems to be no fast way of getting through this.
There are many Slackers who could help, but they have to volunteer. Pure Slackers tend to
be much like pure Debians --- stuck in their own little command line world and ambivalent
toward improvements. I have used Slackware many years and recently Debian and have seen
this behavior among the purists.
On the other hand, many Slackers do not trust binaries from anywhere except the stock
packages provided by the distro maintainer. Most tend to build their own non-stock
packages. This is a peculiar behavior but one I have learned to accept in the Slackware
community. I build my own packages too, mostly out of habit, but I'm not religious
about that. There really isn't an audience of Slackware users like (K)Ubuntu users who
want 100% point-and-click. There is a strong vein of Slackware users who detest
point-and-click.
As with every single distro community, there are people in the Slackware community who
argue what is and what is not the "Slackware Way." Generally, the presumed
"Slackware Way" is for end-users to compile their own packages from build
scripts. Build scripts are readily available at several popular web sites, but building is
presumed an end-user responsibility.
Unlike many distros, the default stock Slackware installation includes a full development
environment. Thus the tools are all available to perform these tasks. People new to
Slackware soon discover this mentality when they post questions at the forums. If they do
not possess the motivation to build packages, then they are softly encouraged to move on.
I have fought this philosophy many times to no avail. Never try teaching pigs to sing ---
you waste your time and irritate the pigs.
The point is that offering to host binary packages might be a moot point.
Perhaps offering to provide build scripts is all you need. Both of us can do that.
As far as syncing the online Slackware mirrors, I use a shell script with rsync that I run
manually and from cron. I run the script here every Saturday afternoon from cron. I
maintain my own local mirror for releases 12.2, 13.0, 13.1 and Current. You probably would
save much time and bandwidth by not syncing the KDE4 packages and sources.
There are a handful of command line package managers, but I think the rsync script is what
you seek.
Slackware packages previous to release 13.0 use a compressed tar gzip format (tgz). From
13.0 thereafter the package system uses tar xz (txz). Hence the urgency to get Ark to
recognize those formats. :)
I have notes/comments in my build scripts that I need to add dependency checking.
Historically, Slackware itself does not provide dependency checking when building or
installing packages. Overall most Slackers prefer this, including me. For this project I
want to add those checks.
Right now my build scripts only remind the user that certain packages must be rebuilt and
that the stock 3.5.10 packages cannot be installed or the builds will fail. Right now my
build scripts check for the tqtinterface package being installed. The scripts terminate if
any dependency packages are not installed.
I designed my build scripts to function with your SVN and to support people who want to
individually patch the stock 3.5.10. The default is to build SVN packages.
I have not yet progressed to testing with releases 13.0, 13.1, or Current. I have only
tested with 12.2. With those three more recent releases I would need to rebuild the
dependency packages. I then probably would focus on adding some dependency checks and
rebuilding options.
This is a huge project. I wish I could encourage other Slackers to get involved. There are
some really sharp Slackers out there who could move this project faster than me. My web
site stats show Slackers are visiting my web page devoted to this project. Yet nobody is
offering to help. I am hoping that perhaps when I get the basics rolling and confirm all
the packages at least build, that then some of those people might become more interested
when they see the improvements you've added to 3.5.10. Hence my interest in parsing
the svn logs to create a more readable change log for use as a marketing tool.
Possibly part of the lack of interest is the Slackware maintainer declared 3.5.x dead and
the die-hards are going to follow blindly. Most people are under the illusion that qt3 is
a problem. They do not know that you are building the interface required to adapt to qt4.
I think if more people knew that there might be more interest in 3.5.x.
My (hopeful) attitude right now is "if we build it they will come."
Important is I need to get to the point where all of these packages build without incident
AND I am using them on a daily basis. If I am eating my own dog food then that might
encourage people to become involved.
I appreciate what you mentioned previously about how much you have to do at your end. With
the current response among Slackers, at moments I wonder whether all the work I am doing
is only for me. :) Well, if that is the case, this won't be the first time a person
scratched his or her own itch. If others benefit from my work without helping then great
but I get no less than I seek. If I had even rudimentary C++ skills I would be trying to
patch things like crazy.
In summary, let's proceed with all of this one day at a time. Otherwise I'll
overload!
Darrell