[Dev] R: Acerca de libretools/About libretools

[Nicolás Reynolds]

> Libretools _was_ perfect for that task `aur ruby-rails` but it seems
> like `aur` try to run `vimdiff` and fails without notice. Shouldn't
> dependencies be managed automatically? Or handle the missing program?

i think you refer to this commit[0], it uses DIFFTOOL from
libretools.conf, which defaults to vimdiff but it can be any diff'ing
tool that receives "file.new file.orig" as argument (it should be the
other way around, now that i say it).

it only applies when the package dir already exists, previous to that
you'd loose all your changes.

> I think __modifying scripts for personal use when they should be
> generic is a problem__.
> 
> Also, we have 3 from 8 points in [Joel Spolsky's test] [Joel test] (4
> questions do not apply):
> 
> 1. Version Control.
> 2. One step packaging.
> 3. Bug database.
> 
> We are missing:
> 
> 4. Fixing bugs before writing new code.
> 5. Up to date schedule.
> 6. Specs.
> 7. Quality Assurance.
> 8. Usability tests.
> 
> I would add:
> 
> 9. Effective and updated Docs.
> 
> I think __it's important to do something about it because libretools
> is getting hard to maintain__ (`toru` is broken, a lot of duplicated
> code...)  __and adapted to few's personal workflow__ (forced `vimdiff`
> on `aur`?).
>
>> It is important.  Although toru works for some specific workflows, it
>> isn't documented enough and probably has bad defaults.
>> 
>> Having both fullpkg and treepkg for different workflows might be a
>> part of the same problem.

treepkg is a rework of fullpkg, because it was becoming too long and
hard to maintain. i also started to experiment a different workflow that
has better results for me on mips64el and that i have discussed with
mtjm on irc but never here - sorry.

treepkg solved the problem of a package(1) and its dependency(2) needing
the same one(3), but fullpkg putting (3) after (2) or at the same
level. treepkg finds this and moves (3) before (2), and then runs the
packaging command from (3) to (1). it's also cleaner than fullpkg IMO.

i've written some documentation here[1].
 
> I'm not going to start inmediately, but I'm starting with `fullpkg`
> specs and it's unit tests. BTW, https://bugs.parabolagnulinux.org/ is
> down.

i think this is the time to say that "my experiments" are over and i've
found it much more comfortable to work from *inside* the chroot rather
than outside. this avoids mounting and unmounting /{dev,proc,sys} and
package caches because you can have them on fstab as bind mounts
(currently systemd fails at them but `mount /chroot/*` solves it.

also you can use plain `makepkg` instead of `libremakepkg` and having to
chroot if the build fails (or start all over if you have the centuries,
or fix the bugs to make it use makepkg flags correctly), a thing that i
do a lot when i package for i686.

if you don't like a stripped down work environment (without your config
files) i simply bind mount my ~ into it - but you'll have to edit
pkgbuilds with your favorite editor from another shell.

either way, i think treepkg can be adapted to use libremakepkg, chroot
cleanup and stage/release tools if you don't like this workflow. i admit
i haven't been using fullpkg lately, but git log shows me it's been
mature with a lot fewer commits :B

> [chiliproject]: https://www.chiliproject.org/
> [chili aur]: https://aur.archlinux.org/packages.php?ID=3D60338
> [joel test]: http://www.joelonsoftware.com/articles/fog0000000043.html



[0]: https://projects.parabolagnulinux.org/libretools.git/commit/?id=9808018ca09050ade144d0dfc0b0b6edadefa368
[1]: https://projects.parabolagnulinux.org/libretools.git/tree/doc/treepkg.markdown
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20120920/80a57b6c/attachment.sig>