Normally I avoid charged and lengthy discussions but as the opinion of
other maintainers was solicited in this correspondence, I thought I'd
let you know my modest opinion as briefly as possible:
Facilitating dependency queuing for possible optional parsing tools is a
logical evolution of the
ubject: [Slackbuilds-users] requirements in README files
Date: Mon, Jul 9, 2012 20:45
On Mon, Jul 9, 2012 at 9:00 PM, David Spencer <
baildon.resea...@googlemail.com> wrote:
>
> Yeah, long chains of indirect dependencies are a pain. They'd be even
> more of a pain if o
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 req
Quoting Christoph Willing :
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
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. f
Quoting Jan Herrygers :
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 s
Am 10.07.2012 23:20, schrieb Ben Mendis:
>
> I can't speak for anyone else on this thread, but this is what I would
> like to see. This is exactly what I am supporting.
>
Me too,
I did a quick incomplete and inacurate search on the README files in the
13.37 repo and it seems that a minimum of 800 a
On Tue, Jul 10, 2012 at 5:02 PM, Jan Herrygers wrote:
> 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 than separated by "
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 "simplifi
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 '.'
>
>
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 t
2012/7/10 J :
> 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 languages, like
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
Quoting TuxaneMedia :
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.
I think that do
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, f
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 th
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 depend
Understood. So what is the opinion of admins on this?
Quoting Erik Hanson :
On Tue, 10 Jul 2012 11:52:49 -0500
JK Wood wrote:
> Quoting TuxaneMedia :
>
>> The admins do alter README files and it looks like this is getting the
>> way to go:
>>
>> "This requires zope.component and gaphas "
is
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:
On Tue, 10 Jul 2012 11:52:49 -0500
JK Wood wrote:
> > Quoting TuxaneMedia :
> >
> >> 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 chime in? if this i
Would you be so kind as to read a little further down? Perhaps the bit
where I replied to Chess?
Quoting JK Wood :
On Jul 10, 2012 11:31 AM, "J" wrote:
Well, morning folks. why is it always morning when one works nightshift?
so not fair. anyway.
so, first off, sbotools already exists a
On Jul 10, 2012 11:31 AM, "J" 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 the
parsing
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
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
subjec
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
subje
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 wrote:
>
>
> On Tue, Jul 10, 2012 at 9:10 AM, Nick Blizzard > wrote:
>
>> With respect, changing a compression scheme or moving on to x64
>> hardw
On Tue, Jul 10, 2012 at 9:10 AM, Nick Blizzard
wrote:
> 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 cor
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
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
w
On Jul 10, 2012 7:00 AM, "David Spencer"
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 happen, I'd hope that both b
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 with
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
subje
On 10/07/2012, at 5:02 PM, LukenShiro wrote:
Il giorno Tue, 10 Jul 2012 10:42:10 +1000
Christoph Willing 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 th
Il giorno Tue, 10 Jul 2012 10:42:10 +1000
Christoph Willing 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 doesn't by default
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 ma
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 w
On Mon, Jul 9, 2012 at 9:00 PM, David Spencer <
baildon.resea...@googlemail.com> wrote:
>
> Yeah, long chains of indirect dependencies are a pain. They'd be even
> more of a pain if our flexible source-based locally-managed dependency
> resolution was more rigid. There's nothing better than noti
> My suggestion would be for a
> PREREQS="..." line in the .info file
Maybe that could be X-PREREQS, in an homage to Usenet headers :-)
-D.
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinf
For simple cases, I've noticed over the past year, or maybe more, that
some of the admins do impose a consistent form of words on new
submissions and updates, so the situation is probably getting better
(statistically). And now that I have seen the form of words that the
admins seem to like, I try
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 other
> Quoting Doogster :
> > 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 :
> > I am absolutely against of such en
On Mon, 9 Jul 2012 23:57:40 +0100
"Greg' Ar Tourter" wrote:
> 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
> the slack-require
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
multimedia
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 http:/
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 cases
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 r
Quoting Doogster :
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 :
I am absolutely against of such enforcement. Because next
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 wrote:
> 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
I am absolutely against of such enforcement. Because next step will be
automatic dependency resolver and I don't think somebody wants it.
I'm not an author of any public SlackBuild's, just ordinary user. I
think it will bring more harm than profit. I know how hard to
determinate requirements manual
* J wrote:
> 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.
So far, the status quo of README files has worked for me. One is
supposed to read them anyway, remember?
Maybe sbopkg is more tu
Hallo, J,
Du meintest am 09.07.12:
> 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.
The README is created from the author/maintainer of the program. The SBO
maintainer should not change i
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, perl-Date
52 matches
Mail list logo
