1 |
On 09/08/17 10:43, William L. Thomson Jr. wrote: |
2 |
> On Wed, 9 Aug 2017 10:29:40 +1000 |
3 |
> "Sam Jorna (wraeth)" <wraeth@g.o> wrote: |
4 |
> |
5 |
>> On 09/08/17 04:20, William L. Thomson Jr. wrote: |
6 |
>>> On Tue, 8 Aug 2017 19:32:48 +0200 |
7 |
>>> Kristian Fiskerstrand <k_f@g.o> wrote: |
8 |
>>>> - You might be applying local patches through /etc/portage/patches |
9 |
>>>> that are distributed to all clients |
10 |
>>> |
11 |
>>> This might be the strongest reason. Though would only apply to stuff |
12 |
>>> like say kernel sources. Not sure what patches could be applied to a |
13 |
>>> binary ebuild, -bin. A patch would not effect src_install per my |
14 |
>>> understanding. |
15 |
>> |
16 |
>> There's also the fact that binpkgs may be manually installed exactly |
17 |
>> as the package manager would have installed it, rather than extracting |
18 |
>> whatever upstream supplies verbatim. |
19 |
> |
20 |
> What then is the benefit? If what is installed is the same from |
21 |
> package manager or binpkg. Also your redistributing another's package |
22 |
> in binary format which may not be legally allowed. |
23 |
|
24 |
The difference is that how the package manager/ebuild installs the |
25 |
package may be better suited to the environment than what upstream |
26 |
expects (such as upstreams that install through a .run file) |
27 |
|
28 |
>> This includes things like any wrappers, desktop files or symlinks |
29 |
>> created by the ebuild, or other such downstream-isms. |
30 |
> |
31 |
> If it was made via package manager. If it was made via quickpkg, it |
32 |
> maybe different than if made by package manager. |
33 |
|
34 |
Using quickpkg can create different binaries depending on your options, |
35 |
but otherwise it should package any installed files as recorded by the |
36 |
package manager - provided you use inclusive options, there should be no |
37 |
appreciable difference as far as I'm aware. |
38 |
|
39 |
-- |
40 |
Sam Jorna (wraeth) |
41 |
GnuPG ID: D6180C26 |