[Slackbuilds-users] Was forking SBo (Hijacked) - Now: Why bother forking?

Thu Jul 12 22:42:11 UTC 2012

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

On 07/12/2012 06:39 AM, Christoph Willing wrote:
> 
> On 11/07/2012, at 5:30 PM, J wrote:
> 
>> Another thing which has been mentioned a few times, and which I have
>> considered off and on myself, is a fork of the repo. There are several

I thought I had missed something here. But really, after realizing that
I had previously read the quote above, so there was no topic openener
(w/o the "Re:"). The thread was hijacked.

Please, when you do something like this, Put a "WAS" or something in the
subject line to show some continuity so people aren't looking for the
original post that doesn't exist.

There was another post in this very long and interesting thread that
mentioned three things:

1.) The situation where there is an XOR in the deps. The example used
was wxPython and wxGTK.

2.) The situation where the dep for a package must be >=, <=, or between
some version values.

3.) The situation where the scheme for versioning suddenly changes.

Personally, I think that talk of mucking about with the .info is
actually the best way to handle dependency checking. Perhaps it would be
easier to use an entirely new construct in the form of a .dep file - one
dependency per line, and when the dependencies are an XOR requirement,
then placing both on the same line. For example:

<code>
# dvdstyler.dep
dvdauthor
ffmpeg
libavc1394
libmspack
libquicktime
mjpegtools
mpgtx
wxPython wxGTK
wxsvg
</code>

Of course, in the example above, I didn't bother to check the order in
which these deps must be installed, or address the fact that build
options may need to be passed to any particular SBo.

A layer specifying such build options could easily be implemented in
such a .dep file. Maybe it would look like this?

<code>
# dvdstyler.dep
'dvdauthor'
'ffmpeg FAAC=yes FREI0R=yes LAME=yes X264=yes XVID=yes'
'libavc1394'
'libmspack'
'libquicktime'
'mjpegtools'
'mpgtx'
'wxPython' 'wxGTK'
'wxsvg'
</code>

And of course we've introduced five additional dependencies at this
point into the quagmire.

Not addressed is what do do when the version must be greater than and
less than some value.

Also, in sbopkg we have the "-k" switch, which in the case of using
queuefiles  would skip borking the ffmpeg that most of us chose to use
from Eric's offshore package repo.

And that kind of brings us full circle doesn't it? I mean, if you want
dependency checking and resolution, isn't the following a much simpler
model to use?

<code>
# cd /var/lib/sbopkg
# git clone
git://gitorious.org/sbopkg-slackware-queues/sbopkg-slackware-queues.git
queues
# sbopkg -i dvdstyler.sqf -k
</code>

And so far the discussion of automatic dependency resolution doesn't
even begin to address issues like OpenCascade, which needs ~2.6GB of
/tmp space and build options like "INSTALL_FULL_DOCS=yes
./OpenCASCADE.SlackBuild", or optional dependencies  such as FreeImage,
libtbb and gl2ps (From
http://slackbuilds.org/repository/13.37/graphics/OpenCASCADE/ ) - which
is one of the main strengths of NOT having dependency checking in
Slackware in the first place!

No offense, but what does Salix do for situations like this? Make the
decisions for you? I think that's why they make distros especially for
stupid people, like the distro for stupid people - ewboontew.

Even Fedora and Debian make all of these choices for you, and in the
case of things like ffmpeg, one has to learn enough about how to use
alternative (I hate that word) repos, which just brings us back to why
Slackware is so strong in this area.

sbopkg is a wonderful tool, itself capable of dependency resolution by
incorporating the example I gave above, but in doing so, we're making
the conscious decision to let someone else make those decisions for us
which may yield the expected outcome if you don't first do your homework
at SBo.org. i.e., "sbopkg -i dvdstyler.sqf"  or "sbopkg -i
OpenCASCADE.sqf", for a couple of real world examples.

I remember years ago when I was sailing (not motoring, which means I
pretty much had the right of way regardless) into Newport. Some fricken
Cap'n Crunch in one of those Grand Banks motoryachts was makin' a
beeline for me and didn't yield. I honked at him with the airhorn and
tacked to avoid the collision, seeing that the asshat wasn't going to
alter his heading.

Considering the amount of traffic in and out of that harbor it was more
than a little scary, seeing that big motoryacht bearing down on us in
such an arrogant and condescending manner (Not to mention illegal).

As that vessel passed on its way out to the ocean, we starting yelling
and cussing until it was obvious that no one was at the wheel.

This was back in the beginning of the GPS days, and there were indeed
idiots that went so far as to plug in several waypoints to navigate
their way in and out of anchorages - as insane as that is.

Well, when that boat got about a hundred yards astern of us we saw Cap'n
Crunch emerge from the salon to the deck w/a fresh cocktail in one hand,
and what looked to be a plate of fingerfood in the other, all  decked
out with his little skipper hat and his yacht club jacket.

I was so livid I didn't bother to get the name off the stern of that
boat, but looking back, I'm sure it read: "EwBoonTew Newport Beach, CA".

Maritime law dictates that you will ALWAYS have a man on watch when
underway. But so does common sense.

Hey, it would be wonderful if I could just type something like
"slackstall get vlc wireshark geany handbrake --askops" and be able to
choose from a dialog of every possible option for every possible dep and
their respective options - but cloning SBo is not going to come anywhere
near to that.

I actually believe in the layers of separation that afford innovation
and encourage the research and development of greater levels of
sophistication, built upon the accomplishments of others who maintain
systems already sufficiently vetted by the Slackware community. slackpkg
is one such tool that was entered into the mainline distro, while sbopkg
is built upon the stability of SBo.

It would become increasingly difficult to continually heap more and
greater responsibilities upon the volunteer SBo package maintainers, and
the only real complaints to the model have been in the form of naysayers
of Slackware (It's not official), or people who want dependency resolution.

There have been, and in fact are still, tools and distros that already
address this in some fashion or another. Slapt-get, SalixOS, and others,
but in following in series after package management solutions that are
already considered by most to be stable, reliable, and accepted/adopted
by the largest cross-section of the Slackware community, I can think of
two things that might take advantage of this layering upon previous
schemes, while insuring that work is not duplicated or even having to
recreate the wheel.

1.) A dedicated group to maintain sbopkg queuefiles into the future.

2.) a new (bash or curses/dialog based) tool to parse those queuefiles
for all possible deps and their associated options, including additional
optional deps and build time options, that acts upon that queue prior to
invoking sbopkg.

This approach would ensure that existing methods for customization and
installation and tracking are still maintained and available, as well as
permitting higher levels of usage that build upon existing tools,
instead of re-inventing the wheel.

Even then, that's no excuse for not looking at the readme for each
slackbuild.

I hope that helps :)

- -- 
Bradley D. Thornton
Manager Network Services
NorthTech Computer
TEL: +1.310.388.9469  (US)
TEL: +44.203.318.2755 (UK)
TEL: +41.43.508.05.10 (CH)
http://NorthTech.US

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Find this cert at x-hkp://pool.sks-keyservers.net

iQEcBAEBAwAGBQJP/1LCAAoJEE1wgkIhr9j3yPUH/jNgJnS2bjli5eIPQ7q00vGl
zSezfVBKcRnKShr0EE2TSayXi1tgmPq9LJmyAYHdWU3bQ+OcAZq65VdQKtCuSvmj
M1mqfa4YHjdzuROA9UpXTQUPnE0EPNo+azlezv771A5mV6m7I5sLjq1LIGjWnsYB
jcu4ejZ9B3emivCQ0M0pnOQw4RjnJJU5CLC5ZPJ3OS0fty07R+oQoKpY8+7G7J8c
P9YdWy52jf9NiseWsVrdJoIvU15SoX5Kq6IyxAHMgBzAlS04B8bdbKSHmfjdG6lQ
PKPYKl8SS5Jx6V2pt0YgnHvd/Xbloobw5+LxQ+Y4t2CJN82DECsKcWYHeS1ymPk=
=l0f8
-----END PGP SIGNATURE-----