slackbuilds.net - Slackware

This is a discussion on slackbuilds.net - Slackware ; -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Please note that at this time, this is very bad form and could result > in some crazy behavior. The problem is a simple one, and one we > should have solved soon. ...

+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3
Results 41 to 46 of 46

Thread: slackbuilds.net

  1. Re: slackbuilds.net

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1


    > Please note that at this time, this is very bad form and could result
    > in some crazy behavior. The problem is a simple one, and one we
    > should have solved soon. The variable values in the info files are
    > not quoted, so it's possible to see something like:
    >
    > DOWNLOAD=http://www.foo.bar/foo-1.tar.gz&rm\ -fr\ \/


    this is not a matter, you use fakeroot or su -c no ? NO! arf, sorry for you
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.7 (GNU/Linux)

    iD8DBQFHVaY99sCa4LW0nIwRAr+6AJ9PwkJ+urQYnTA6dDS6nt l88hBYrACcDOgs
    19o2EoRTQgAIoYWNB0jIoO4=
    =SJ6I
    -----END PGP SIGNATURE-----

  2. Re: slackbuilds.net

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1


    > Please note that at this time, this is very bad form and could result
    > in some crazy behavior. The problem is a simple one, and one we
    > should have solved soon. The variable values in the info files are
    > not quoted, so it's possible to see something like:
    >
    > DOWNLOAD=http://www.foo.bar/foo-1.tar.gz&rm\ -fr\ \/


    this is not a matter, you use fakeroot or su -c no ? NO! arf, sorry for you
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.7 (GNU/Linux)

    iD8DBQFHVaaD9sCa4LW0nIwRAln+AJ9NfXoBpbOF56yXdg2E5D fwCr65BQCff+kD
    5pV3Sh4OMglN7UvkDr4AeTw=
    =N90Z
    -----END PGP SIGNATURE-----

  3. Re: slackbuilds.net

    > The two projects are maintained by different groups and with different
    > goals. Use whichever you prefer, though fo obvious reasons I prefer
    > SBo.
    >
    > SBo (my short-hand from slackbuilds.org) tries to make build scripts
    > available that are as "true" to how we feel Pat would make them himself.
    > In other words, there's no extraneous dependency management beyond a
    > README file, everything is pacakged up in /usr, and by and large we try
    > to keep them as simple as possible. Each script in our repository is
    > checked over by at least 1 member of the admin team to ensure that it is
    > "perfect" (for some definition of "perfect"). We try to weed out any
    > major problems and ensure that each will compile just fine on a stock
    > Slackware installation.
    >
    > I cannot speak for slackbuilds.net as I am unfamiliar with that project.


    first message isn't pass, I hope this one do.
    When I talk about "dependancies manager" it was a joke. Really is simply
    a line commented : #Depends:soft1,sof2,... for help de packager to find
    other slackbuilds in svn. All soft are not mentionned in this line : only
    those aren't in Slackware. So, a real "manager" isn't it ? There is
    README file only if something is important to say : "gtk-last break xfce,
    trac need a subversion with swig support, ...", not systematicly. Some
    patches can be included, only if there is very usefull, or be included on
    the next version of the soft. Patch for candies features simply ignore.

    Another thing, is testing. A SlackBuilder must test his SlackBuild on a
    vanilla Slackware. I don't know if I say, but it's simply stupid to
    provide a SlackBuild that is not test and build the package on a vanilla
    slackware. An exemple is Vym. On my Slackware it just work fine ! Of
    course, I've got qt-4, but Slackware provid qt-3, and vym-last do not
    build on qt-3. This is an uncouth exemple, but other exemple exist : trac
    works fine on my Slackware, because I've got subversion rebuild with
    swig, if not, trac not display websvn ... and exemple like this there is
    thousand.

    Finally, all packages build via scripts from SlackBuilds.net are also
    perfect :
    - correct PATH
    - slack-desc
    - goods permissions
    - gzip man pages
    - strip libraries and binaries when avaible (some binaries cannot be
    stripped)
    - all important file in /usr/doc/pkg-version (even if the LHS indicated /
    usr/share/doc)
    - what else ? all is simply good

    Using sbn or sbo, the most important is to edit the script before launch
    it, otherwise, just take a binary somewhere in the web.

    --
    aster, with a ****ing open nntp server working ... sometimes

  4. Re: slackbuilds.net

    In article <1196764239.28@user.newsoffice.de>,
    Manuel Reimer wrote:

    > ciol wrote:
    >
    > > Manuel Reimer wrote:
    > >> If a script fails to execute with fakeroot, then you may fix it and
    > >> post the fix to the mailing list. I'm sure the fix will be added.

    >
    > > The fix is to accept that you are wrong and that you should do what
    > > slackbuild.net does.
    > > Only chown and makepkg are done with fakeroot:

    >
    > Why? All the checks in ./configure will do well with fakeroot, as


    That's incorrect. Even the man page of fakeroot states that fakeroot
    will confuse configure.

    You should only run fakeroot for those commands for which you actually
    need fake root privileges, such as 'chown' and 'makepkg'. The build
    process itself should not ever run in a fakeroot environment.

    > fakeroot just spoofs file owners to be root where they arent in real.
    > This causes "tar" to create a valid tgz package.


    No, it does more than that -- it remembers the faked effects of 'chown'
    for instance. Read the man page.

    - Martijn

  5. Re: slackbuilds.net

    On 2007-12-04, Olive wrote:
    >> I have nothing against using someone using fakeroot if they
    >> desire, but the SlackBuilds.org project has no plans to support
    >> it in our builds. If that makes us "wrong" then I guess we'll
    >> just be "wrong" (along with official Slackware).

    >
    > Patrik Volkerding has probably his reasons which I do not know. But
    > there is a tendency by some persons on this list to consider P.V. as a
    > kind of divinity and simply answering "P.V do the same" is not a
    > sufficient answer. I you do a choice; please have arguments. I am sure
    > that P.V. does not take its decision simply because someone that he
    > considers "perfect" do the same.



    Nor do I. Of course, I didn't intend that statement to mean that we
    were doing it that way because that's how Pat does it, but then, we
    do try to stay as "true" to Slackware as possible. Ultimately, it's
    not an issue of whether our approach is "perfect" -- it's not.
    Neither are the other alternatives (fakeroot, etcetera). It's simply
    a matter of looking at the options and choosing the one that best
    fits, and for us, that option is to align with official Slackware as
    much as possible.

    On a related note, that's why we don't accept scripts in our repo
    for things that are part of the official Slackware package tree.
    We have no desire to try to maintain parts of official Slackware,
    and in fact, I don't think it's a good idea at all to install newer
    versions of things that are part of Slackware unless you actually
    *need* some new functionality offered in the new package version.
    I've seen too many cases of people wanting the "new and shiny"
    version numbers of software, and in the process of getting it (or
    attempting to so), they make things exponentially worse. Anyway,
    that's another subject, so I'll hush...


    >> It distills to a matter of trust - either one trusts the team
    >> to release tested scripts that don't do "Bad Things" or one does
    >> not. If one does not trust our team, then by all means, don't
    >> use our stuff - it's that simple.

    >
    > I must say that although I valuate and use slackbuilds.org; I do not
    > agree. I do not think you will intentionaly put damaging scripts on
    > slackbuilds.org but what if a mistake. Quite often the upstream author
    > recommends not building as root for this reason (as an example among
    > other read the README in the Linux kernel source). Nobody can just say
    > that he will never do a mistake; I would not even put such a trust in
    > myself.



    Well, yeah, nobody's perfect - that's for sure. I still posit that it
    is indeed a matter of trust. You trust that the build scripts (and
    resulting packages) in official Slackware will not do Bad Things to
    your system, and very rarely does that happen (and when it does, it's
    in the -current development tree, where it's a known risk). The same
    applies to our project and the others - either you trust the maintainers
    or you don't. I personally think we as a group have a pretty damn good
    track record, but of course, I'm biased

    On a related note, the "nobody's perfect" idea is exactly why we don't
    unilaterally place our *own* scripts into our repository. For example,
    I've got 10-12 waiting in our pending queue, another maintainer has
    5-6 in it, and there's probably another with one or two in it, but as
    a matter of policy, we require another team member to test and approve
    our own submissions, just like any other submission. Of course, if the
    changes are trivial (typographical errors, simple version bumps, ...),
    then we typically waive that requirement, but you get the idea.


    > Another problem is if someone want to modify a script. When I do that I
    > would be much more comfortable with the fakeroot approach. Also using
    > fakeroot is more comfortable for the person who write the scripts (I
    > have written a few scrits).



    Perhaps it is, and like I said earlier, I have no problem with fakeroot
    in general. It is not, however, in the official Slackware package tree,
    and until/unless that changes, we will not require it or support it as
    a means of creating packages with our build scripts.

    -RW

  6. Re: slackbuilds.net

    ciol wrote:
    > Obviously you have never tried it.


    I've tried this several times.

    AFAIK it's pretty common on Debian systems to use fakeroot to create
    deb packages.

    CU

    Manuel


+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3