Project

General

Profile

Bug #248

[libremakepkg] behave more like makepkg

lukeshu - over 11 years ago - . Updated almost 11 years ago.

Status:
fixed
Priority:
feature
Category:
-
Assignee:
% Done:

100%


Description

It should be makepkg + chroot + libre-checks*

*librenamcap?


Related issues

Blocked by libretools - Bug #247: [libremakepkg] Don't require the user to know the libremakepkg/makechrootpkg/makepkg relationshipfixed2012-11-28

Actions
Blocked by libretools - Bug #152: [libremakepkg] support repackagingnot-a-bug2012-07-24

Actions
Blocked by libretools - Bug #147: [libremakepkg] doesn't symlink to the packagefixed2012-11-28

Actions
Blocked by libretools - Bug #71: [libremakepkg] doesn't stop immediately when unknown option are foundfixed2012-04-07

Actions

History

#2

Updated by mtjm over 11 years ago

Is there any use for this freedom check unless the packager has nonfree packages available on their system? If blacklist has foo:foo-libre:, listing foo-libre in dependencies will make updates from foo-libre to fixed foo harder, if blacklist has foo:: then the packager cannot install the package or its dependencies without using non-Parabola repos with the nonfree package. Or is there a different case when this check is useful?

(It also doesn't seem arch-specific unlike the rest of what libremakepkg does.)

#3

Updated by lukeshu over 11 years ago

The checks will include things more than they currently do. For example, checking license files, for some common machine-checkable issues in the source directory, etc. Also, it dissables networking during build() and package(), as some software cleverly tries to download binaries during the build process.

#5

Updated by lukeshu almost 11 years ago

Done in git; invocation is almost identical.

Also available in: Atom PDF