[gentoo-dev] Need clear semantics for packages with binary entities

[gentoo-dev] Need clear semantics for packages with binary entities

[trupanka]

I’m suffering from the fact that users can distinguish packages containing
binaries just by eye. There is no mechanism to allow/ignore such packages.
For license restrictions we have ‘package.license/’ whitelist.

I figure out the following binary entities in portage’s packages
that (to my point of view) need to be clearly defined as BINARY:
1. *-bin packages (maven-bin, icedtea-bin)
2. firmware packages (linux-firmware)
3. purely binary packages that are installed without any notion
they are binary or source packages just like Ubuntu’s ones
(app-office/upwork)
4. packages with pre-compiled bytecode/objectcode that are installed
like packages in #3.
(geogebra, many packages with .jar files in dev-java/*)
5. packages with ‘-binary’ USE-flag. Semantics of ‘-binary’ differs:
(seabios) binary     : Use official upstream pre-built binaries
(ghc) binary        : Install the binary version directly, rather than
using it to build the source version.
(scala) binary : Install from (Gentoo-compiled) binary instead of
building from sources. Set this when you run out of memory during build.
(etc...)
6. packages that need binaries to compile/bootstrap (sbcl)
7. to be continued... I guess

#1 semantics has no control. Such packages may be installed as a
dependency
without warnings they are binaries.
#5 semantics are not clear (defined in manifest.xml)

The only binary entities under users’ control are:
1. packages from “PKGDIR” installed with ‘emerge --usepkg’
2. packages with -binary USE-flag

I wonder if Gentoo’s devs can do something with the problem.
I think it’s problem in source-based Linux distribution.

Re: [gentoo-dev] Need clear semantics for packages with binary entities

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1373 bytes --]

On Mon, 28 Dec 2015 21:24:14 +0300
trupanka@gmail.com wrote:

> I’m suffering from the fact that users can distinguish packages containing
> binaries just by eye. There is no mechanism to allow/ignore such packages.
> For license restrictions we have ‘package.license/’ whitelist.
> 
> I figure out the following binary entities in portage’s packages
> that (to my point of view) need to be clearly defined as BINARY:
> 1. *-bin packages (maven-bin, icedtea-bin)
> 2. firmware packages (linux-firmware)
> 3. purely binary packages that are installed without any notion
> they are binary or source packages just like Ubuntu’s ones
> (app-office/upwork)
> 4. packages with pre-compiled bytecode/objectcode that are installed
> like packages in #3.
> (geogebra, many packages with .jar files in dev-java/*)

And you already covered here how different the notion of 'binary' (or
rather, 'pre-built') can be. There could be pre-built stuff that is
arch-specific or otherwise of limited portability. There could be
pre-built stuff that is portable. There could be pre-built stuff whose
rebuilding isn't really meaningful at all.

Do you want to force rebuilding docs in every package? Do you want to
force eautoreconf to ensure you don't run pre-built configure scripts?

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] Need clear semantics for packages with binary entities

[Kristian Fiskerstrand]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 12/28/2015 07:33 PM, Michał Górny wrote:
> On Mon, 28 Dec 2015 21:24:14 +0300 trupanka@gmail.com wrote:
> 
>> I’m suffering from the fact that users can distinguish packages
>> containing binaries just by eye. There is no mechanism to
>> allow/ignore such packages. For license restrictions we have
>> ‘package.license/’ whitelist.
>> 

..

> 
> And you already covered here how different the notion of 'binary'
> (or rather, 'pre-built') can be. There could be pre-built stuff
> that is arch-specific or otherwise of limited portability. There
> could be pre-built stuff that is portable. There could be pre-built
> stuff whose rebuilding isn't really meaningful at all.

Sure it is, at least a reproducable build in order to compare and
ensure no malware being installed. I'm reading this more from a
security point of view than performance, and the question makes
perfect sense.

- -- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJWg8pgAAoJECULev7WN52FTnYIAJoUrTdQCH4FkfvGR1HLIS0B
SBg/GymkzWsWh0v2iTpW1RSG8R1fFbZn1sZwyKve5GOW+WaxQz5a5P731UiB5h5I
cHiy9FfoCSpDadNqIVhyx+NMB10W1yiPoe7sea98ZtYsAWlrpAEbfHtvHVcfveNg
HuxjAKu1cLil9XdZ9GHSMpEPcgq0LoKY2q3Mrq/J+XwUs1akSOa2NrX9QFSdpmJA
hbustOWRqqLWkCXrDwau19J1LuM8HPFoiviA00qGmvOtp+RcZT+1NuHRYFCR4wI9
W9eYj8zWs/HzcubmheuY0Mk6D3Jkp1nxrsgvq9uceXTZ0TUqqD3JZzWUX/vIV2k=
=vjF1
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Need clear semantics for packages with binary entities

[Zac Medico]

On 12/28/2015 10:24 AM, trupanka@gmail.com wrote:
> I’m suffering from the fact that users can distinguish packages containing
> binaries just by eye. There is no mechanism to allow/ignore such packages.
> For license restrictions we have ‘package.license/’ whitelist.

We can use the PROPERTIES variable (or alternatively the RESTRICT
variable) to tag this information in the ebuild. Portage has a
ACCEPT_PROPERTIES configuration variable, and a package.properties file
that can be used to mask and unmask packages based on PROPERTIES. It
would be useful to be able to do this with "live" ebuilds too...
--
Thanks,
Zac

Re: [gentoo-dev] Need clear semantics for packages with binary entities

[Chí-Thanh Christopher Nguyễn]

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

trupanka@gmail.com schrieb:
| I’m suffering from the fact that users can distinguish packages
| containing binaries just by eye. There is no mechanism to allow/ignore
| such packages.

| 7. to be continued... I guess
7. fonts which come precompiled instead of being built from source (e.g.
through fontforge)
8. artwork which is pre-rendered to bitmap formats but originally sourced
from vector graphics (e.g. KDE icons)
9. packages which download additional binary things later (Android SDK,
hplip depending on your printer)
10. documentation which is downloaded as PDF but not as DocBook/TeX/... sources
11. ... (I'm sure there are more)

| I wonder if Gentoo’s devs can do something with the problem. I think
| it’s problem in source-based Linux distribution.

I believe that Debian uses the term "preferred form for modification" to
describe/categorize their builds in that regard.


Best regards,
Chí-Thanh Christopher Nguyễn

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlaEc1UACgkQ+gvH2voEPRCi6QCeNFoY/NWU0zXqf8B/F2tm1ZaB
y7QAni7MdYwoOQHn/1xQd8x2lsB5zc4n
=yQrF
-----END PGP SIGNATURE-----