Project

General

Profile

Bug #648

[RFC] Purpose and rigidity of librechroot/libremakepkg and related tools

alfplayer - over 6 years ago - . Updated over 2 years ago.

Status:
not-a-bug
Priority:
discussion
Category:
-
Assignee:
-
% Done:

0%


Description

The chroot package builder tools in Libretools is inflexible in many ways. Even if some of these are configurable or fixable, they are default behaviour:

  • Hard-coded files. Examples:
  • The complexity limits hacking to knowledgeable people.
    As an example, the attached file shows a libremakepkg process tree. Building without a chroot only requires makepkg.
  • clean-pkgs, which I believe runs every time before a package is built, removes chroot packages which are not (recursive) dependencies of the package to be built.
  • There are no Libretools commands to make changes inside the master chroot, or it's not documented (librechroot -l could work).
  • To build a package, the current directory must be in the abslibre tree controlled by Libretools. However, releasing packages does not allow uncommited files, so the tree can't be used for programming or testing.

I can recognize two different purposes of chroot package building tools like librechroot and libremakepkg: automation of package building on clean chroots, and validation of packages to respect packaging policy. Libretools seems to be focused on validation and following packaging policy, but not on providing clean chroots to aid the creation of packages. Maybe global validation/release and testing modes can be added to fill these separate purposes.


Files

libremakepkg-process-tree (665 Bytes) libremakepkg-process-tree alfplayer, 2015-01-19 02:03 AM

History

#1

Updated by fauno over 6 years ago

+1 to the subject, i lost track of libretools long time ago :P

#2

Updated by lukeshu about 6 years ago

Ping me on IRC so we can discuss this.

fauno: yeah, but you lost track way back when xihh was still developing it :P

#3

Updated by lukeshu about 6 years ago

There are no Libretools commands to make changes inside the master chroot, or it's not documented (librechroot -l could work).

That is the intended way to do it. -l root. I guess I thought with the way the documentation was, that would be clear. What would be a good way of clarifying the docs?

#4

Updated by lukeshu about 5 years ago

BUILDDIR="/build"

FWIW, Debian later standardized on this for reproducible builds. Beating Debian to the punch, since 2015 :P

#5

Updated by lukeshu about 5 years ago

  • Priority changed from wish to discussion
  • Subject changed from Purpose and rigidity of librechroot/libremakepkg and related tools to [RFC] Purpose and rigidity of librechroot/libremakepkg and related tools
#6

Updated by alfplayer about 5 years ago

Hacking documents could really help with this, and/or source file comments, to describe important processes, commands, file paths and maybe functions.

#7

Updated by lukeshu over 2 years ago

  • Status changed from open to not-a-bug

I'm going to go ahead and close this. There's been no discussion in 2 years. The mirrorlist bit is the only part I still think is valid; and #623 is open for it.

Also available in: Atom PDF