[Slackbuilds-users] requirements in README files

Tue Jul 10 13:10:37 UTC 2012

With respect, changing a compression scheme or moving on to x64
hardware isn't core to Slackware... the simplicity of the package
management system, and not being forced to include any dependencies,
managing those yourself... that's core to slackware.

is there any way to make this pointless debate / discussion end?

On Tue, Jul 10, 2012 at 9:07 AM, Ben Mendis <dragonwisard at gmail.com> wrote:
> I truly respect all of this reverence for "the Slackware way", however that
> really feels like an excuse. A few years ago it wasn't "the Slackware way"
> to run on 64-bit x86, but now it is. It also wasn't "the Slackware way" to
> use xz compression, but now it is. Before that it wasn't "the Slackware way"
> to use an automated tool to download and install/update packages, but then
> slackpkg was added. And so on. What is or isn't "the Slackware way" isn't
> set in stone. It's a combination of how we, as Slackware's user community,
> choose to run Slackware and Pat V's whim.
>
> While I generally trust Pat V's whim, I think that his perspective in this
> specific case may be biased. What he and his team do to maintain the
> Slackware OS is different in some fundamental ways from how the user
> community interacts with the system and especially with third-party software
> like the stuff on SBo.
>
> Look, nobody here is claiming that dependency resolution is an easy problem
> to solve generically for all cases. However, just because it's a hard
> problem doesn't mean we should ignore the problem or lie to ourselves and
> call it a "feature". Let's acknowledge it.
>
> Dependency resolution is a very hard problem. Nobody else has a perfect
> solution for how to do it either.
>
> But just because it's a hard problem doesn't me we have to throw our hands
> up and not do anything. Just because there are corner cases and exceptions
> doesn't mean that it's useless to even try. This isn't about solving a
> problem which may, in fact, be an unsolvable problem. It's about making that
> problem a little less annoying in some of the most common and easiest to
> handle cases. The vast majority of cases on SBo are low-hanging fruit in
> problem space of dependency resolution.
>
> Currently, Slackware's package tools wouldn't even know that dependency
> information exists, let alone how to enforce it. And nobody here has
> suggested that that should change. All that we're saying is that it would be
> nice if it were possible to _partially_ automate the resolution of the
> dependency graph. And when you run into those corner cases that everyone
> keeps harping on like wx* and different version requirements and optional
> dependencies or whatever else, then the it would still be the sysadmin's
> role (YOU) to resolve those just as manually as you always did before.
>
>
> I'm not saying I want portage. If I did I would be using Gentoo instead of
> Slackware. I *love* the way that Slackware handle's packages, and I love how
> the package tools deal with dependencies (specifically, that they don't).
> However I think that having optional tools that help resolve dependency
> graphs would still be a HUGE improvement over the
> hours-of-tab-hell-using-paper-and-pencil method that we have now. It would
> cut out the low-hanging fruit in the process leaving you to just verify the
> list and fill in some blanks. Minutes of manual work instead of hours of
> manual work.
>
> On Tue, Jul 10, 2012 at 12:54 AM, Chess Griffin <chess at chessgriffin.com>
> wrote:
>>
>> First, a couple of disclaimers:
>>
>> 1.  I started the sbopkg project and was soon joined by slakmagik and
>> Mauro Giachero, both of whom made sbopkg far better than I ever could
>> have done by myself.   I retired in 2010 and handed the project over to
>> slakmagik who has done a great job in continuing to maintain it along
>> with help by Mauro.  I thank them both for their past and future help.
>>
>> 2.  I used to be a SlackBuilds.org admin but also retired from that
>> role.  I know what it's like to be an admin and to test the submissions.
>>  It's a lot of work, and what I did paled in comparison to what the
>> other admins did, and continue to do.  I am not an admin any longer, so
>> I don't speak for the SBo project in any capacity.
>>
>> Having said that, I think the point made earlier by T3slider that the
>> SBo project is not intended to be a do-everything script repository is
>> spot on.  IMHO, the SBo project is simply intended to provide a
>> repository of SlackBuild scripts just like the ones that Pat creates for
>> official Slackware packages.  Since those official SlackBuild scripts
>> don't have any kind of dependency information, neither do the SBo
>> scripts (other than what the maintainer decides to put in the README).
>>
>> When slackmagik, Mauro, and I came up with the idea of the sbopkg
>> queuefiles, the point was to only try to automate what the user would
>> otherwise do manually.  We've all sat down with a paper and pencil and
>> written out our list of SBo packages to build and, after reading through
>> the READMEs, figured out the right order of build dependencies.  The
>> queuefiles is intended to be simply a way to "save" that information to
>> make it easier to build the packages again later on.  Is sbopkg or its
>> queuefiles perfect?  Certainly not.  But, it really was written with the
>> "Slackware way" in mind and I think overall, it works well.  Sbopkg
>> doesn't try to figure out anything for you -- the user still has to put
>> in the initial work -- but sbopkg can make life a little easier by
>> saving this information in a simple text file we call a queuefile for
>> future use.
>>
>> I understand the OP's point and yes, I can see a case where having a
>> standardized format for including compile-time dependencies in the
>> README or .info file would be helpful.  But that's never been the
>> Slackware way so putting that in place would move the SBo project from
>> its original purpose, at least as I see it.
>>
>> Finally, and here is where I put on my "former SBo admin" hat on, if the
>> SBo project were to change things and start requiring that build-time
>> dependencies be included in the README or .info file, then this would
>> definitely lead to more work for the current SBo admins, who already put
>> in a lot of time in maintaining SBo.  The fact is that many SlackBuild
>> script maintainers are not that communicative (and I've been guilty of
>> this myself -- I only just now got to updating OpenArena after /many/
>> requests -- sorry!) and either the admins would have to try and track
>> down all the maintainers to update their submissions to the new format
>> or do it themselves.  And, of course, test the listed dependencies.
>> What if someone forgot to add a dependency?  Each submission would have
>> to be tested on a clean, newly installed system in a VM or something to
>> ensure that the dependencies were listed correctly and in the right
>> order.  That's a lot of work.
>>
>> Ultimately, I think Slackware, and the SBo project, are geared toward
>> those who are willing to put in some of their own effort when it comes
>> to adding third-party software.  I use FreeBSD (and OpenBSD) as well so
>> I am familiar with their ports and packages systems.  And, for the most
>> part, they work well.  And I was even a FreeBSD port maintainer for
>> awhile.  But those systems were built with that kind of dependency
>> tracking from the outset and Slackware SlackBuild scripts were not.
>> Therefore, any such dependency tracking is a bolted-on solution.
>>
>> I have no idea if the current SBo admins are considering adding
>> dependency information like the OP suggested.  Maybe so, maybe not.  And
>> whatever they decide is fine by me.  Either way, I really appreciate all
>> the hard work the SBo admins and the SBo Slackbuild script maintainers
>> put in.  The SBo project is a huge, and I mean HUGE, benefit to the
>> Slackware community.
>>
>> Just my < $0.02.  :-)
>>
>> --
>> Chess Griffin
>> _______________________________________________
>> SlackBuilds-users mailing list
>> SlackBuilds-users at slackbuilds.org
>> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
>> Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
>> FAQ - http://slackbuilds.org/faq/
>>
>
>
> _______________________________________________
> SlackBuilds-users mailing list
> SlackBuilds-users at slackbuilds.org
> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - http://slackbuilds.org/faq/
>
>