Quoting Christoph Willing c.will...@uq.edu.au:
On 11/07/2012, at 2:01 PM, J wrote:
[snip]
1. how does such a recommendation get communicated to slackbuild
maintainers? admins out there, would you be willing to publish such
a recommendation on slackbuilds.org? after all, if it weren't
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
reasons I have not pursued this idea; it constitutes an amount of work
which would keep me busy doing that for an unrealistic amount of time,
or it
Il giorno Tue, 10 Jul 2012 10:42:10 +1000
Christoph Willing c.will...@uq.edu.au ha scritto:
A listing of build prerequisites is even more innocuous - no
particular need for that to appear in a final package at all. My
suggestion would be for a PREREQS=... line in the .info file
(which
On 10/07/2012, at 5:02 PM, LukenShiro wrote:
Il giorno Tue, 10 Jul 2012 10:42:10 +1000
Christoph Willing c.will...@uq.edu.au ha scritto:
A listing of build prerequisites is even more innocuous - no
particular need for that to appear in a final package at all. My
suggestion would be for a
Am 10.07.2012 06:54, schrieb Chess Griffin:
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.
I don't know if I remember it 100% correctly, but I think we had the
subject
For the record I'm personally not 100% hostile to the idea. I could
live with a formal mechanism for declaring mandatory direct
dependencies, but I wouldn't stay up late myself to make it happen.
If it ever did happen, I'd hope that both build-time and run-time
dependencies should be included
On Jul 10, 2012 7:00 AM, David Spencer baildon.resea...@googlemail.com
wrote:
For the record I'm personally not 100% hostile to the idea. I could
live with a formal mechanism for declaring mandatory direct
dependencies, but I wouldn't stay up late myself to make it happen.
If it ever did
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
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
On Tue, Jul 10, 2012 at 9:10 AM, Nick Blizzard
nickblizzard1...@gmail.comwrote:
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
Optional dependency graph resolution is NOT a slippery slope to turning
Slackware into Debian or Gentoo.
On Tue, Jul 10, 2012 at 9:21 AM, Ben Mendis dragonwis...@gmail.com wrote:
On Tue, Jul 10, 2012 at 9:10 AM, Nick Blizzard nickblizzard1...@gmail.com
wrote:
With respect, changing a
Am 10.07.2012 06:54, schrieb Chess Griffin:
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.
I don't know if I remember it 100% correctly, but I think we had the
subject
Am 10.07.2012 06:54, schrieb Chess Griffin:
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.
I don't know if I remember it 100% correctly, but I think we had the
subject
Well, morning folks. why is it always morning when one works
nightshift? so not fair. anyway.
so, first off, sbotools already exists and has some
requirement-parsing, it is how I deal with slackbuilds.org myself. and
I continue to hack on the parsing code to improve it for the gazillion
On Jul 10, 2012 11:31 AM, J j...@dawnrazor.net wrote:
Well, morning folks. why is it always morning when one works nightshift?
so not fair. anyway.
so, first off, sbotools already exists and has some requirement-parsing,
it is how I deal with slackbuilds.org myself. and I continue to hack on
Would you be so kind as to read a little further down? Perhaps the bit
where I replied to Chess?
Quoting JK Wood joshuakw...@gmail.com:
On Jul 10, 2012 11:31 AM, J j...@dawnrazor.net wrote:
Well, morning folks. why is it always morning when one works nightshift?
so not fair. anyway.
On Tue, 10 Jul 2012 11:52:49 -0500
JK Wood joshuakw...@gmail.com wrote:
Quoting TuxaneMedia j...@tuxane.com:
The admins do alter README files and it looks like this is getting the
way to go:
This requires zope.component and gaphas
is this absolute fact? can we get some admins to
eh, I think you're assuming that every maintainer on SBo would be
happy that you will make modifications to the README of the stuff
they're maintaining to make your tool happy, but I won't be that sure
of this.
remember that nobody stops you to fork the repo and modify the
slackbuilds as you like:
Understood. So what is the opinion of admins on this?
Quoting Erik Hanson e...@slackbuilds.org:
On Tue, 10 Jul 2012 11:52:49 -0500
JK Wood joshuakw...@gmail.com wrote:
Quoting TuxaneMedia j...@tuxane.com:
The admins do alter README files and it looks like this is getting the
way to go:
On Tue, Jul 10, 2012, at 11:31 AM, J wrote:
where you're dead wrong is the stuff about
testing. what in the world does all that have to do with anything? the
testing process wouldn't change one iota from where it currently stands.
Right now, it's up each maintainer to list the
Am 10.07.2012 18:31, schrieb J:
is this absolute fact? can we get some admins to chime in? if this is
fact, and all admins are doing it and following the same format, then
this means that for 14.0 we'll have consistency, and my work here is
done.
No, not fact, but experience (just from the
Thanks for clearing that up, I now see where you're coming from. And I
believe you're misunderstanding; please all me an attempt to clarify:
My request is related *strictly* to formatting, and goes absolutely no
further. So that if someone submits a slackbuild with the requirement
listed,
Quoting TuxaneMedia j...@tuxane.com:
But did you ever think of getting the info you need from another source
as the SlackBuild ?
Deps should always be almost the same for a package
Maybe think of the LFS Project which lists dependencies always the same
way , even required and optional ones.
On 10/07/2012 18:44, J wrote:
Thanks for clearing that up, I now see where you're coming from. And
I believe you're misunderstanding; please all me an attempt to
clarify:
My request is related *strictly* to formatting, and goes absolutely
no further. So that if someone submits a slackbuild with
2012/7/10 J j...@dawnrazor.net:
This requires x, y, and z.
since that is currently the most popular format and so it makes sense to
adopt that as the format in question.
a small thing that comes to mind: this form is easily parseable with
perl, but it won't be that easy with other scripting
I did it.
#!/bin/bash
read LINE
LINE=${LINE/This requires /} # Remove the leading 'This requires'
LINE=${LINE/and /} # Remove the 'and '
LINE=${LINE%.} # Remove the trailing '.'
while [ ${#LINE} != 0 ] # loop until the line is empty (fully-processed)
do
PKG=${LINE%%, *} # grab the
Or just
sed 's/^This requires //;s/, /\n/g;s/ and /\n/g;s/.$//'
:-)
10.07.2012 21:48, Ben Mendis пишет:
#!/bin/bash
read LINE
LINE=${LINE/This requires /} # Remove the leading 'This requires'
LINE=${LINE/and /} # Remove the 'and '
LINE=${LINE%.} # Remove the trailing '.'
while [
Op dinsdag 10 juli 2012 12:44:58 schreef J:
Thanks for clearing that up, I now see where you're coming from. And I
believe you're misunderstanding; please all me an attempt to clarify:
You want to build a tool that simplifies building a dependency graph. You
already stated that this
On Tue, Jul 10, 2012 at 5:02 PM, Jan Herrygers janherryg...@dommel.bewrote:
But publishing a recommendation doesn't hurt, and it can be beneficial for
the
human reader too.
I woul like a list delimited by newlines and/or tabs (perhaps multiple
spaces?) That would IMHO be much more readable
Quoting Jan Herrygers janherryg...@dommel.be:
Op dinsdag 10 juli 2012 12:44:58 schreef J:
Thanks for clearing that up, I now see where you're coming from. And I
believe you're misunderstanding; please all me an attempt to clarify:
You want to build a tool that simplifies building a
On 11/07/2012, at 2:01 PM, J wrote:
[snip]
1. how does such a recommendation get communicated to slackbuild
maintainers? admins out there, would you be willing to publish such
a recommendation on slackbuilds.org? after all, if it weren't stated
there, it wouldn't exactly be worth much.
2.
I'm wondering if there's any hope at all of perhaps enforcing
slackbuilds to have a consistent format in their README files for
listing requirements.
Currently we see a very wide variety of formats. While the most
popular looks something like:
This requires perl-Params-Validate,
You're trying to parse requirements out of README files?
Are you trying to to write something like Portage for SBo?
On Mon, Jul 9, 2012 at 9:20 AM, J j...@dawnrazor.net wrote:
I'm wondering if there's any hope at all of perhaps enforcing slackbuilds to
have a consistent format in their README
Quoting Doogster thedoogs...@gmail.com:
You're trying to parse requirements out of README files?
Are you trying to to write something like Portage for SBo?
No, something like FreeBSD's pkgtools:
http://dawnrazor.net/sbotools/
Quoting Yaroslav Panych panyc...@gmail.com:
I am absolutely
See here: http://slackbuilds.org/faq/#deps
The omission of parsable information is an intentional one as far as I
know. In order for dependency resolution to come to SBo, there would
need to be a way of identifying mandatory vs. optional dependencies.
Additionally, if there is special information
I believe the OP was just suggesting a less ad-hoc way to describe
build dependencies.
Of course thats not always uncomplicated; nevertheless for some large
percentage of software, the prerequisite packages required to build
some new software are quite clear. Why not accommodate these
sbopkg has a queue file facility which allows your to create list of
package to build in a certain order. Mauro used to maintain a
repository of queue file for all packages available in slackbuilds.org
but I suspect he has been busy with other things lately. you can get
the queue files from
I have to agree with this. 95% of the time I vastly prefer the classical
Slackware approach to package management to what I've seen in other distros
or other Unix(-like) systems. However there are a few cases where
build-time or run-time dependency trees can get pretty crazy. Many of the
On Mon, 9 Jul 2012 23:57:40 +0100
Greg' Ar Tourter artour...@gmail.com wrote:
snip
Adding dependency management is the not slackware way of doing thing
and it is a can of worm that most people here would not want to see
open. Slackbuilds.org follows very closely the way Slackware works and
Quoting Doogster thedoogs...@gmail.com:
You're trying to parse requirements out of README files?
Are you trying to to write something like Portage for SBo?
No, something like FreeBSD's pkgtools:
http://dawnrazor.net/sbotools/
Quoting Yaroslav Panych panyc...@gmail.com:
I am
On 10/07/2012, at 8:57 AM, Greg' Ar Tourter wrote:
sbopkg has a queue file facility which allows your to create list of
package to build in a certain order. Mauro used to maintain a
repository of queue file for all packages available in slackbuilds.org
but I suspect he has been busy with
Hello folks.
Have to go to work shortly so I don't have time to say much.
Even if I did, I wouldn't reply to the raging-against-dependency
emails, cause that's a dead-horse we've been beating for over a
decade, so long that I don't even care anymore; these days I care
about things that
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
43 matches
Mail list logo
