Re: [gentoo-dev] RFC: Proposal for addition of distribution variables

[A. Wilcox]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 15/12/16 17:03, Michał Górny wrote:
> On Thu, 15 Dec 2016 21:49:15 + "Robin H. Johnson"
>  wrote:
>> 1. ebuilds: Add eclass to export all variables from
>> /etc/os-release with a prefix: OS_RELEASE_ID OS_RELEASE_NAME 
>> OS_RELEASE_PRETTY_NAME OS_RELEASE_BUG_REPORT_URL etc (I'm happy
>> to bikeshed the name of the variable prefix).
> 
> I'm not really into exporting a not-well-defined set of variables.
> This would mean that e.g. OS_RELEASE_FOO would be explicitly
> exported if os-release specifies FOO=, and otherwise it would leak
> from the parent environment.
> 
> I think it'd be better to bind it to specific variables (possibly
> all defined os-release vars atm) and clear those that are not
> specified.


I hadn't realised the wording of this sentence when I replied.  Yes,
that seems like a bad way to go; it should have a set of variables
that will be exported to ebuilds.  And perhaps fall back to the
profile for anything not provided.


>> 1.1. Upstream packages that natively read from /etc/os-release
>> will automatically be supported. 1.2. Could potentially be in
>> base.eclass.
> 
> base.eclass is in process of being nuked, so please don't
> reintroduce that horrible creation. Separate eclasses for specific
> purposes are the way to go, not huge monsters that do everything.


As I said in last email, I plan to make 'branding.eclass'.  No base.


>> 2. Introduce a new virtual: virtual/os-branding.
> 
> I don't mind having a virtual for this but tbh I don't see much of 
> the point in it. Are we going to allow users to switch branding at
> runtime? ;-)
> 
> Or is this purely because you find overriding virtual in subdistro 
> cleaner than overriding a package? On one hand, I would agree with 
> that. On the other, that would mean that users will find eternally 
> uninstallable packages due to blockers -- i.e. redundant.


As someone who is running a subdistro: virtuals cause me even more
pain than real packages, as I have to constantly chase || dep list,
and when it is updated, normally there is no version bump (it is
eternally virtual/whatever-0 or virtual/whatever-1) so I have to go in
and change again.  I agreed simply because package.provided exists.

But I already have to 'override' sys-apps/baselayout, due partially to
licensing concerns and partially to the fact it has Gentoo branding
everywhere.


>> 4. sys-apps/baselayout: 4.1. Move all branding pieces OUT of
>> sys-apps/baselayout, into per-distro packages, that satisfy
>> virtual/os-branding. 4.2. Depend on virtual/os-branding (maybe
>> implicit via the eclass above?)
> 
> Wouldn't it be better to put it into @system? And possibly engage
> some releng quirks.


@system has no guaranteed merge order.  It would be better to make it
implicit via eclass, for two reasons I can think of:

1) It will pull in the package before it is needed.  Guaranteed.
2) On embedded/crossdev, the only package in @system is busybox.  So
there is no branding present.  That means that virtual/os-branding
would be useless bloat, unless and until a package that uses it is
installed (at which case it could be installed anyway).


Just my two cents.  Thank you.


Best,
- --arw


- -- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJYU0FUAAoJEMspy1GSK50UWvoP/AiNspWMoqTz9WXEDOhSWdPe
XEMSvjnMHoDvc7ETpKWiCPHx6bOB+S/B/sGwdSU4H7hHCg5a5JukzHToXwaVZRgm
pO+W5084kJIRSMDsOo5xRN8B9tQqfBdmZwvsJHJ7pGHrP38m6iLm04FTbn1kbc/Q
CyCAStRmTs0NROcJFXEIZAyDJohdvhWBk2CLKcou2zhcLmZDwMuOJaHM85FK+7fg
9+DDrehBfbIM+YuSKz52A++sUwRTofnkGPzGycfL+UGmbEB6JrU6tSem5YyQpxe2
UZzsmJUzvY75hh1yvqeh7Ye6DPY2l0UYFkY24SVO/QlSkqXr9qJNYo8gJ7Un7y/4
aGpQnbNgus/dioHvTLcQnWeipBiGCal3EBJEkh9hKzPrJsLmpn2Ogh/+OJsxdw4S
qMQCgqA3vB9wDig5JatSootGSPyAOAEOyQ3I8fkpj96bz2T7pgxX9wvGnkfKXIVY
CTqdYJjQCAnxfFBujoN6AUiTMVaXBhewS7O6TOLJiszVqhlAsjbLeza/xY4vrpgG
VzmakLygqkmY3+xgqLcgqFOkazAr6ZldxaDERVV0lvRcs8sr+3ycXTRnpudB8EdT
x5rvwsUaLqn0OWjTGnPdsmkt/WgWw2vEfCdnMqjW84VeQCjMHBbikLJmj+oVaqoB
q7MlTp0uHpQQ51X4ESy/
=lGeb
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: Proposal for addition of distribution variables

[Mike Gilbert]

On Thu, Dec 15, 2016 at 4:49 PM, Robin H. Johnson  wrote:
> 3. The distro branding package (v1) (providers of virtual/os-branding):
>- MUST have NO build dependencies that require execution (this could
>  be the very first package in a bootstrap).
>- MUST install /etc/os-release
>- /etc/os-release MUST provide the following values
>  - NAME, ID, PRETTY_NAME, HOME_URL,
>- /etc/os-release MAY provide other values.
>- MAY provide hardcoded values for /etc/os-release
>- MAY read values from profiles for /etc/os-release
>- MAY install any other branding files (logos, artwork, trademark,
>  notices, etc)

A technical note here: we should probably install /usr/lib/os-release
instead of /etc/os-release.

https://www.freedesktop.org/software/systemd/man/os-release.html

Quoting the above:

The file /etc/os-release takes precedence over /usr/lib/os-release.
Applications should check for the former, and exclusively use its data
if it exists, and only fall back to /usr/lib/os-release if it is
missing. Applications should not read data from both files at the same
time. /usr/lib/os-release is the recommended place to store OS release
information as part of vendor trees. /etc/os-release should be a
relative symlink to /usr/lib/os-release, to provide compatibility with
applications only looking at /etc. A relative symlink instead of an
absolute symlink is necessary to avoid breaking the link in a chroot
or initrd environment such as dracut.

Re: [gentoo-dev] RFC: Proposal for addition of distribution variables

[Michał Górny]

On Thu, 15 Dec 2016 21:49:15 +
"Robin H. Johnson"  wrote:

> I do really agree that how we offer branding should be covered in a
> GLEP, and be very easy for downstream offshoots of Gentoo to follow.
> This would prevent future concerns like the Ubuntu branding / modified
> VM spats.
> 
> [snip awilfox's superb proposal; I agree with all of the reasons and
> outcomes, but think a little bit more structure & flexibility are
> needed].
> 
> On Mon, Dec 05, 2016 at 08:46:53AM +0100, Michał Górny wrote:
> > Strictly speaking, it could use $EPREFIX/etc/os-release which has all
> > the info you need, is installed by baselayout and doesn't require
> > special wrappers to print it.  
> ...
> > The other alternative is to provide an eclass that reads data from
> > $EPREFIX/os-release and supplies it to the packages that need it.  
> 
> I've been wondered about this, since reading awilfox's PR, and I have
> some tweaks & extensions to offer to their proposal. This resolves all
> of the drawbacks noted by mgorny, supports branding information via
> profiles (or other means).

Thanks. I like it. A few comments though.

> 0. This proposal is centered around using os-release, as a
>cross-distribution model.
> 1. ebuilds: Add eclass to export all variables from /etc/os-release with
>a prefix:
>OS_RELEASE_ID
>OS_RELEASE_NAME
>OS_RELEASE_PRETTY_NAME
>OS_RELEASE_BUG_REPORT_URL
>etc
>(I'm happy to bikeshed the name of the variable prefix).

I'm not really into exporting a not-well-defined set of variables. This
would mean that e.g. OS_RELEASE_FOO would be explicitly exported if
os-release specifies FOO=, and otherwise it would leak from the parent
environment.

I think it'd be better to bind it to specific variables (possibly all
defined os-release vars atm) and clear those that are not specified.

> 1.1. Upstream packages that natively read from /etc/os-release will
>  automatically be supported.
> 1.2. Could potentially be in base.eclass.

base.eclass is in process of being nuked, so please don't reintroduce
that horrible creation. Separate eclasses for specific purposes are
the way to go, not huge monsters that do everything.

> 2. Introduce a new virtual: virtual/os-branding.

I don't mind having a virtual for this but tbh I don't see much of
the point in it. Are we going to allow users to switch branding
at runtime? ;-)

Or is this purely because you find overriding virtual in subdistro
cleaner than overriding a package? On one hand, I would agree with
that. On the other, that would mean that users will find eternally
uninstallable packages due to blockers -- i.e. redundant.

> 3. The distro branding package (v1) (providers of virtual/os-branding):
>- MUST have NO build dependencies that require execution (this could
>be the very first package in a bootstrap).
>- MUST install /etc/os-release
>- /etc/os-release MUST provide the following values
>- NAME, ID, PRETTY_NAME, HOME_URL,

BUG_REPORT_URL was also deemed important.

>- /etc/os-release MAY provide other values.
>- MAY provide hardcoded values for /etc/os-release
>- MAY read values from profiles for /etc/os-release
>- MAY install any other branding files (logos, artwork, trademark,
>notices, etc)

I'm not sure if we need to be that specific in what it does. I think
that stating that it can go first in bootstrap should be enough ;-).

> 4. sys-apps/baselayout:
> 4.1. Move all branding pieces OUT of sys-apps/baselayout, into
>  per-distro packages, that satisfy virtual/os-branding.
> 4.2. Depend on virtual/os-branding (maybe implicit via the eclass
>  above?)

Wouldn't it be better to put it into @system? And possibly engage some
releng quirks.

-- 
Best regards,
Michał Górny



pgpAaRMrLWYLG.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Proposal for addition of distribution variables

[A. Wilcox]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 15/12/16 15:49, Robin H. Johnson wrote:
> I do really agree that how we offer branding should be covered in
> a GLEP, and be very easy for downstream offshoots of Gentoo to
> follow. This would prevent future concerns like the Ubuntu branding
> / modified VM spats.
> 
> [snip awilfox's superb proposal; I agree with all of the reasons
> and outcomes, but think a little bit more structure & flexibility
> are needed].

I posted it to the list with the express intent that I welcomed
improvements.  I'm glad that the community seems to agree this needs
to be done, and that we want to get it right the first time.


> 0. This proposal is centered around using os-release, as a 
> cross-distribution model.

I am interested how this will work :)


> 1. ebuilds: Add eclass to export all variables from /etc/os-release
> with a prefix: OS_RELEASE_ID OS_RELEASE_NAME 
> OS_RELEASE_PRETTY_NAME OS_RELEASE_BUG_REPORT_URL etc (I'm happy to
> bikeshed the name of the variable prefix).


OS_RELEASE_* seems fine to me.


> 1.1. Upstream packages that natively read from /etc/os-release
> will automatically be supported.


Yes, this thankfully includes most modern KDE 5 and XFCE packages.
Still, KDE 4 needs to be told in configure/CMake.


> 1.2. Could potentially be in base.eclass.


What does it do when /etc/os-release doesn't exist?  Would Portage
still be usable?  I am imagining such a thing as: "I accidentally
deleted /etc!  I can recreate most of it using emerge -e world
though."  Also, crossdev / embedded images.


> 2. Introduce a new virtual: virtual/os-branding.


This is an interesting idea.


> 3. The distro branding package (v1) (providers of
> virtual/os-branding): - MUST have NO build dependencies that
> require execution (this could be the very first package in a
> bootstrap).


Ah, I see now.  That would make much sense.  Since it would likely be
static files anyway, it would probably need no DEPEND= at all, I would
hope.


> - MUST install /etc/os-release - /etc/os-release MUST provide the
> following values - NAME, ID, PRETTY_NAME, HOME_URL,


Where does OS_RELEASE_BUG_REPORT_URL come from?  Does it use HOME_URL
if BUG_REPORT_URL is not set?  I suppose that would be acceptable.


> - /etc/os-release MAY provide other values. - MAY provide hardcoded
> values for /etc/os-release - MAY read values from profiles for
> /etc/os-release - MAY install any other branding files (logos,
> artwork, trademark, notices, etc)


It could RDEPEND on sys-boot/ logos and such.  Not sure that large
desktop backgrounds and the like should be required on small embedded
images that have no displays though.  Perhaps artwork could be in IUSE.


> 4. sys-apps/baselayout: 4.1. Move all branding pieces OUT of
> sys-apps/baselayout, into per-distro packages, that satisfy
> virtual/os-branding.


That is also interesting.  So other distros could then use the Gentoo
baselayout package without having /etc/gentoo-release files and so on.
 Good idea.


> 4.2. Depend on virtual/os-branding (maybe implicit via the eclass 
> above?)
> 


Hmm.  If it goes in base.eclass, everything would depend on it.
Including virtual/os-branding itself?  Not sure how Portage
could/would handle such a thing.

If there were to be a branding.eclass, it would certainly make things
much easier.  It would also give more explicit knowledge of what
packages were using it, instead of grepping the tree for ${DISTRO} and
the like, you could simply see what packages inherit branding.

If work lightens up I will try to get something hammered out by
Friday.  Otherwise, I will probably have something by the weekend.

Thanks!

Warm regards,
- --arw


- -- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJYUx3sAAoJEMspy1GSK50UFF0QAMOxiiqwX0uR5Ubx7ZHQj5qL
5iHK/KPQW9tR4vumtCRy/xppK2xvQ7uQbyZWsVekfUmqji/YH3+KoKyy0ffuFryA
DpEQ7Gar/J1dXLainriTxfpFxuDHMO2OEzcUxpYD7PJ5snj9I7ED1e5KtxZnW3XQ
lpccCBKbtcmiEum3bODGwFr3PI7awpiZZBRZZgDpP+Am8ibnMeYuST4ROcem58RO
7b8TQIcVMQmtJLpZSc64WFwOZ22SRRBz4TXkaWrUC+6+swhSXqWuMkMwSYYZVmBt
8HIMKBOrS25bi4BEIft/+p68DVeYJLGp3d2SAM3DBlkgDV2FsicHp9+m/DTZXPYA
4JUvv+n/sROudEeUj2MP9j5XMarSl2uZHoNeBKIM64AtxL05hdXKj+bXofCEIgXh
4/TPq275cMIMfWFHuNy1/zh/DYJ0emE5RekFx1oCj4i37+HU72moft6Ndtdkxz/p
FlwRonpouE4mBQ8H4wPkJ3wWPaVpL6k33adPRKnycjid1JhA+a9Qnsr1ZoILzfc6
6ieNEtSHiX6C5CbrEIlkaiAhzgGwUlq+dkjakIWBibPHUSJgg8tU2fyzaIO+o90A
Z2Y5uikUFW5GCRLTAPC5e7Tfx0yfGhyR5CSWkkyexAE86YDj/72BU967UfnQznEp
rQkL+Ax+1C1FJSj5JIa2
=7adt
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: Proposal for addition of distribution variables

[Robin H. Johnson]

I do really agree that how we offer branding should be covered in a
GLEP, and be very easy for downstream offshoots of Gentoo to follow.
This would prevent future concerns like the Ubuntu branding / modified
VM spats.

[snip awilfox's superb proposal; I agree with all of the reasons and
outcomes, but think a little bit more structure & flexibility are
needed].

On Mon, Dec 05, 2016 at 08:46:53AM +0100, Michał Górny wrote:
> Strictly speaking, it could use $EPREFIX/etc/os-release which has all
> the info you need, is installed by baselayout and doesn't require
> special wrappers to print it.
...
> The other alternative is to provide an eclass that reads data from
> $EPREFIX/os-release and supplies it to the packages that need it.

I've been wondered about this, since reading awilfox's PR, and I have
some tweaks & extensions to offer to their proposal. This resolves all
of the drawbacks noted by mgorny, supports branding information via
profiles (or other means).

0. This proposal is centered around using os-release, as a
   cross-distribution model.
1. ebuilds: Add eclass to export all variables from /etc/os-release with
   a prefix:
   OS_RELEASE_ID
   OS_RELEASE_NAME
   OS_RELEASE_PRETTY_NAME
   OS_RELEASE_BUG_REPORT_URL
   etc
   (I'm happy to bikeshed the name of the variable prefix).
1.1. Upstream packages that natively read from /etc/os-release will
 automatically be supported.
1.2. Could potentially be in base.eclass.
2. Introduce a new virtual: virtual/os-branding.
3. The distro branding package (v1) (providers of virtual/os-branding):
   - MUST have NO build dependencies that require execution (this could
 be the very first package in a bootstrap).
   - MUST install /etc/os-release
   - /etc/os-release MUST provide the following values
 - NAME, ID, PRETTY_NAME, HOME_URL,
   - /etc/os-release MAY provide other values.
   - MAY provide hardcoded values for /etc/os-release
   - MAY read values from profiles for /etc/os-release
   - MAY install any other branding files (logos, artwork, trademark,
 notices, etc)
4. sys-apps/baselayout:
4.1. Move all branding pieces OUT of sys-apps/baselayout, into
 per-distro packages, that satisfy virtual/os-branding.
4.2. Depend on virtual/os-branding (maybe implicit via the eclass
 above?)

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Trustee & Treasurer
E-Mail   : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136


signature.asc
Description: Digital signature

Re: [gentoo-dev] RFC: Proposal for addition of distribution variables

[A. Wilcox]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/12/16 21:28, Michael Orlitzky wrote:
> Maybe a GLEP with the contents of your first mail? If there's
> consensus for the premise and the implementation, it's easy to add
> the variables. Then it's only a matter of updating ebuilds.

I've tweaked some of the wording and changed to Wiki format from rST
to conform to GLEP 2, and filed bug #602202 [1] to have this formally
added as a GLEP.

Comments are definitely still welcome, either to this list/thread or
my personal email.  I didn't find any reference in GLEP 1 to how
changes can be made to GLEPs already posted on Bugzilla, but I am
definitely open to hearing any that the community has to suggest.

- --arw


[1]: Bug 602202: https://bugs.gentoo.org/602202


- -- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJYS1jDAAoJEMspy1GSK50UXN8P/09uND1/3WMFDT/sn+/gvooR
nFd0V3FHmljoy4EOOTUceYQQBtAPuzRLy8rfNIOtXGyxfx/oHrH1zgqrfugQwl86
KwuXh5t4v5dUQB12TjKtTItITWx48KoedcXM4Pxu73nKo1L7r/jySFFAgOvqDf/P
vdrGOsa1R4uyg/XvC8fDojL5m9SAF60vloHUhQChIp9vhTzxs8PRVi8gIffuZGTq
zrHczroutx4FA0LdsPosEQs9ClO3rbBk/JTuG6WAkgqTeMWDXXAxOyNYMdiQworA
cuO0eU0S3pJcIE6NsbKmZ0qbcJbsgekv/UyBy08r06maOnEt3LbzPRVcOSc50qN8
qQ39DPHnda1bQXINwzeTKq7/2Oly9TjJi4P9c4mUNTeAayRwcvfo/8G16E96/eyj
z2YHYbJytl945S9B1W7fGCzEuCEVOZiXXBvMpu1bO+B0Oonp3zOhwKgqBE/dRZvl
8dAGQzA7LMXb2i1OUTUdtTdbY3cju0t+yYITJ64LKdLWYWgY/m90vttkYE7CHyJO
U33pShFVQuVkHjccT+oWCtI9anZ6Lnjr75PKbi7GlMihQ2hocxH6dmnUZksquLcx
HWE1OZSESVqBUH5PHlBQuJsjVwkrKEdv9Yqtlr0mfk7BYFw9r/5b//pnXzjCqO5e
y+zanHProXl06FjtA9nd
=1NJI
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: Proposal for addition of distribution variables

[Daniel Campbell]

On 12/05/2016 03:49 AM, Rich Freeman wrote:
> Here is a separate thought.  Would it make sense in any way to try to
> have a more established way to communicate with our downstream distros
> about stuff like this, like a gentoo-derivatives mailing list or such?
>  I wouldn't restrict access or anything like that, but participants
> would be expected to stay on-topic (it isn't another gentoo-dev or
> gentoo-user/project).  Changes could still make their way onto the
> main lists.  I was just thinking that we don't really have any
> official way to notify downstream distros of changes like these.

Sounds like a good idea to me. We could even allow technical support
there ala -user, but with a focus on 'remixing' or otherwise
forking/copying Gentoo. It makes sense for a meta distro to assist in
the 'meta' part, if only for informational reasons.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Proposal for addition of distribution variables

[Rich Freeman]

On Sun, Dec 4, 2016 at 11:24 PM, A. Wilcox  wrote:
>
> The original intention wasn't to guess, but I see how PMS is more for
> things that are determined at run-time by the package manager rather
> than static variables.
>

To be clear, PMS is more about package manager behavior, and what
you're defining is more of a repository convention.  You don't need
any special behavior in the package manager to handle these cases, it
is more a matter of repository QA.  It isn't just stuff that is
determined at run-time, but anything that directly impacts the package
manager (such as *DEPEND and so on, which isn't usually set at runtime
but which obviously impacts what gets installed).

A GLEP would be a great way to formalize this IMO, though I'm not
certain it is essential.

Here is a separate thought.  Would it make sense in any way to try to
have a more established way to communicate with our downstream distros
about stuff like this, like a gentoo-derivatives mailing list or such?
 I wouldn't restrict access or anything like that, but participants
would be expected to stay on-topic (it isn't another gentoo-dev or
gentoo-user/project).  Changes could still make their way onto the
main lists.  I was just thinking that we don't really have any
official way to notify downstream distros of changes like these.

-- 
Rich

Re: [gentoo-dev] RFC: Proposal for addition of distribution variables

[Michał Górny]

On Sun, 4 Dec 2016 21:13:23 -0600
"A. Wilcox"  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 04/12/16 20:58, Mike Gilbert wrote:
> > On Sun, Dec 4, 2016 at 6:31 PM, A. Wilcox 
> > wrote:  
> >> Roadmap - ---
> >> 
> >> Since the shell environment is flexible, this change can be 
> >> implemented almost immediately; the defaults specified in the
> >> Gentoo base profile ensure that at worst nothing will immediately
> >> change.  As forks, derivatives, and other organisations change
> >> the environment variables in their profiles or ``make.conf``
> >> files, all updated ebuilds will immediately reflect the changes.
> >> 
> >> During this, the variables can be added to the EAPI=7
> >> specification, and may eventually be added to PMS §11.1.  
> > 
> > It's not clear to me why this should be defined in PMS, especially
> > if this is going to be a profile variable in make.defaults.  
> 
> > 
> > I think we would only need to add it to PMS if you need to package 
> > manager to compute the value based on the running system. Is that
> > what you had in mind here? If so, you will need to include that
> > algorithm in your patch.
> >   
> 
> Thinking on it a little more, that wouldn't be a good way to go.  We
> can't really rely on lsb_release being present, especially if Portage
> is being run on FreeBSD or a more exotic prefix; sys-apps/lsb-release
> isn't even installed on my relatively 'normal' amd64 Gentoo Linux
> machine.  Additionally, it wouldn't have the bug URL even if it were
> present.

Strictly speaking, it could use $EPREFIX/etc/os-release which has all
the info you need, is installed by baselayout and doesn't require
special wrappers to print it.

Benefits of os-release approach:

- distros don't have to override profiles (which can get problematic if
  a distro uses pretty-much standard Gentoo profiles),

- works for people with custom profiles.

Drawbacks of os-release approach:

- can't do it via profiles,

- doesn't work before baselayout is installed.

The other alternative is to provide an eclass that reads data from
$EPREFIX/os-release and supplies it to the packages that need it.

-- 
Best regards,
Michał Górny



pgpwZXyLYTvXm.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Proposal for addition of distribution variables

[Ulrich Mueller]

> On Sun, 4 Dec 2016, A Wilcox wrote:

> Roadmap
> - ---

> Since the shell environment is flexible, this change can be
> implemented almost immediately; the defaults specified in the Gentoo
> base profile ensure that at worst nothing will immediately change.
> As forks, derivatives, and other organisations change the
> environment variables in their profiles or ``make.conf`` files, all
> updated ebuilds will immediately reflect the changes.

I think that the base profile is the right place where you would
define such variables. As you note, you could do that immediately
without any EAPI change.

> During this, the variables can be added to the EAPI=7 specification,
> and may eventually be added to PMS §11.1.

What would be the advantage if the package manager would define such
variables, instead of them being defined in profiles? Package
managers are not specific to any distribution.

Ulrich


pgpUuKnRVarsk.pgp
Description: PGP signature

Re: [gentoo-dev] RFC: Proposal for addition of distribution variables

[A. Wilcox]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/12/16 21:21, Daniel Campbell wrote:
> How would we ensure (or encourage) that other distros based on
> Gentoo would follow this practice? Adding things to PMS isn't a
> panacea, sure, but from what I can tell it seems the goal here is
> to allow distros based on us to correctly *show* that without
> changing hundreds of lines in the package tree. Maybe that's
> outside of PMS; if so, where does this belong?

I would hope people would consult base/make.defaults and write their
own, which would lead them towards the variables they need to set.
However, there was a fair amount of legwork I had to do and find out
with good old trial-by-error when I was writing one.


> Of course, this solution requires action/patching on our behalf as
> well, but it seems like a long-term goal that, when completed, may
> be suitable for addition in some sort of standard document, even if
> it's a wiki page on how to roll your own distro based on us.

I have plenty of experience with that and I would be more than willing
to help write such a page if that is desired.


> It didn't seem to me that there was any intention to automatically
> guess which distro it is; the people in charge of each distro's
> package tree should be setting those variables to the correct
> value, and it should be accessible throughout the tree(s).

The original intention wasn't to guess, but I see how PMS is more for
things that are determined at run-time by the package manager rather
than static variables.


> As OP mentioned, at worst it does nothing until it 'spreads'
> throughout the tree. The end result is anyone could fork us, change
> DISTRO and DISTRO_BUG_URL, and instantly have a starting point for
> their new distro. I'm not aware of any other distro that would make
> forking or spinning off _this_ easy. That could turn into renewed
> interest in Gentoo or possibly even better inter-distro relations,
> since bugs would be going to the correct places.

That is one of the main goals of the proposal.  I feel that Gentoo is
missing out on major contributions because it's so difficult for
people in other distros to provide the patches they write.  Making
spins easier is a definite bonus, and results in more contributions.


> To OP: This idea looks good to me; do you have any proofs of
> concept for use in common places like ebuilds, metadata.xml (if you
> intend for it to be used there), etc? If we had a more visual idea
> of how it worked, maybe more people would understand and have an
> idea of where to put it if it doesn't fit in with PMS's scope.

I have some basic stuff that showed this idea was feasible before I
sent it on, but I don't have anything public yet.  I can start with a
branch (as mentioned in thread) and go from there.

Best,
- --arw

- -- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJYROwTAAoJEMspy1GSK50U6ZEP/2fFOOc1TsABI0lMjE8RFbgM
Jl6c9GGfQJokCQHTTHVOGyUhtDzRztcj3RSOtC5Xopshhj73kPZ+uLkMAhL5jl+6
hQbC6tTYdu6Jqw6ompvqNuaWONnyYfEY8j/fkkop+8YCKZ12rOXD/LtLwaXUMANr
OZP5RDX889q7ZYuel8P7TuyYWK4/F+oVc3T7AOzlPNy68sEAi/L4sGMLupr/geR/
dhPYrC/OSAx2A5zhKfpZCbmm+7fHm0tS3r2SpirTJz2+2fYzbrNbVIE2k5TvMUK3
/dJFzw41W1S8xhebqJoHxslXW5NU6Sj1i7rTMPRHD1jEeuN/nhh29eVt33XIOexi
8G957fie/g5EM3+zcxUCgn+8CSzcCmfgAwUA4MmXgMhqBibk9ZXt7ZlA85WjCQFP
fojVOCgWaNJn9RZjIL9V3UiN4Qjv5kv/m8wjfsH7vwb6DlZ4Kc9NUOVhe2wogNyw
W6WOmnOepolhOlmtB8j9fgKRui9aTU9NO6fhSOXqwvTDn0RzHrELsiGUUNFqjvr2
LE74uJcy7qDtVgCHS6ZRV6YMm9V3L2jPmafS3JfOcY9mA7sZHqR9cW1EF4wpMIAC
eUKDRAG6SwyshZzDJL7V2RmQt64M51diujOQn5M12U8ByQhA5aFnpddIBo+Vbk01
Vg2w69y3HcV4HLU5/2zC
=g8bj
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: Proposal for addition of distribution variables

[Michael Orlitzky]

On 12/04/2016 10:13 PM, A. Wilcox wrote:
> 
> If there are no other objections to this proposal, would a PR that
> implements this against the Gentoo tree be the best way forward?  If
> so, I can start work on that now while giving more people the chance
> to read over it.  (Would it be more desirable to have all changes in a
> single large commit, or one commit per package?)
> 

Maybe a GLEP with the contents of your first mail? If there's consensus
for the premise and the implementation, it's easy to add the variables.
Then it's only a matter of updating ebuilds.

Since the change is essentially a no-op for Gentoo, I don't think it
will be hard to get maintainers to accept the changes. We do however
have to worry about editing stable ebuilds in-place, and maintainers who
are picky about their packages being modified.

You may wind up having to file bugs for a lot of packages that need a
new revision.

Re: [gentoo-dev] RFC: Proposal for addition of distribution variables

[Daniel Campbell]

On 12/04/2016 07:20 PM, Sam Jorna wrote:
> On Sun, Dec 04, 2016 at 09:13:23PM -0600, A. Wilcox wrote:
>> to read over it.  (Would it be more desirable to have all changes in a
>> single large commit, or one commit per package?)
> 
> I'd think this is one of those cases best suited to a branch and merge 
> commit - best of both worlds.
> 
> But that's just my two cents. :)
> 
Yeah. Small, but numerous changes in many different locations aren't
really suited to our usual one-commit-per-logical change bit. It might
be better to branch off, run the sed call or whatever will be used to
update the entire tree, then submit a PR.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Proposal for addition of distribution variables

[Daniel Campbell]

On 12/04/2016 06:58 PM, Mike Gilbert wrote:
> On Sun, Dec 4, 2016 at 6:31 PM, A. Wilcox  wrote:
>> Roadmap
>> - ---
>>
>> Since the shell environment is flexible, this change can be
>> implemented almost immediately; the defaults specified in the Gentoo
>> base profile ensure that at worst nothing will immediately change.  As
>> forks, derivatives, and other organisations change the environment
>> variables in their profiles or ``make.conf`` files, all updated
>> ebuilds will immediately reflect the changes.
>>
>> During this, the variables can be added to the EAPI=7 specification,
>> and may eventually be added to PMS §11.1.
> 
> It's not clear to me why this should be defined in PMS, especially if
> this is going to be a profile variable in make.defaults.
> 
> I think we would only need to add it to PMS if you need to package
> manager to compute the value based on the running system. Is that what
> you had in mind here? If so, you will need to include that algorithm
> in your patch.
> 
How would we ensure (or encourage) that other distros based on Gentoo
would follow this practice? Adding things to PMS isn't a panacea, sure,
but from what I can tell it seems the goal here is to allow distros
based on us to correctly *show* that without changing hundreds of lines
in the package tree. Maybe that's outside of PMS; if so, where does this
belong?

Of course, this solution requires action/patching on our behalf as well,
but it seems like a long-term goal that, when completed, may be suitable
for addition in some sort of standard document, even if it's a wiki page
on how to roll your own distro based on us.

It didn't seem to me that there was any intention to automatically guess
which distro it is; the people in charge of each distro's package tree
should be setting those variables to the correct value, and it should be
accessible throughout the tree(s).

As OP mentioned, at worst it does nothing until it 'spreads' throughout
the tree. The end result is anyone could fork us, change DISTRO and
DISTRO_BUG_URL, and instantly have a starting point for their new
distro. I'm not aware of any other distro that would make forking or
spinning off _this_ easy. That could turn into renewed interest in
Gentoo or possibly even better inter-distro relations, since bugs would
be going to the correct places.

To OP: This idea looks good to me; do you have any proofs of concept for
use in common places like ebuilds, metadata.xml (if you intend for it to
be used there), etc? If we had a more visual idea of how it worked,
maybe more people would understand and have an idea of where to put it
if it doesn't fit in with PMS's scope.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Proposal for addition of distribution variables

[Sam Jorna]

On Sun, Dec 04, 2016 at 09:13:23PM -0600, A. Wilcox wrote:
> to read over it.  (Would it be more desirable to have all changes in a
> single large commit, or one commit per package?)

I'd think this is one of those cases best suited to a branch and merge 
commit - best of both worlds.

But that's just my two cents. :)

-- 
Sam Jorna (wraeth)
GnuPG Key: D6180C26


signature.asc
Description: Digital signature

Re: [gentoo-dev] RFC: Proposal for addition of distribution variables

[A. Wilcox]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/12/16 20:58, Mike Gilbert wrote:
> On Sun, Dec 4, 2016 at 6:31 PM, A. Wilcox 
> wrote:
>> Roadmap - ---
>> 
>> Since the shell environment is flexible, this change can be 
>> implemented almost immediately; the defaults specified in the
>> Gentoo base profile ensure that at worst nothing will immediately
>> change.  As forks, derivatives, and other organisations change
>> the environment variables in their profiles or ``make.conf``
>> files, all updated ebuilds will immediately reflect the changes.
>> 
>> During this, the variables can be added to the EAPI=7
>> specification, and may eventually be added to PMS §11.1.
> 
> It's not clear to me why this should be defined in PMS, especially
> if this is going to be a profile variable in make.defaults.

> 
> I think we would only need to add it to PMS if you need to package 
> manager to compute the value based on the running system. Is that
> what you had in mind here? If so, you will need to include that
> algorithm in your patch.
> 

Thinking on it a little more, that wouldn't be a good way to go.  We
can't really rely on lsb_release being present, especially if Portage
is being run on FreeBSD or a more exotic prefix; sys-apps/lsb-release
isn't even installed on my relatively 'normal' amd64 Gentoo Linux
machine.  Additionally, it wouldn't have the bug URL even if it were
present.

We can therefore strike the PMS bits and the patch from the proposal.


If there are no other objections to this proposal, would a PR that
implements this against the Gentoo tree be the best way forward?  If
so, I can start work on that now while giving more people the chance
to read over it.  (Would it be more desirable to have all changes in a
single large commit, or one commit per package?)

Best,
- --arw

- -- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJYRNtLAAoJEMspy1GSK50UyUAQAJy7whGkLxhjnUR04hT/k0uY
B69MCu3do0TqlAYkpQU/DiCuseeD0UUpXwcUS30RGVUBd6gKsq9vTzAMhvVFEqVM
9wZ+4Gs2yWkMbQ9tOy8rK29fW7M7M4yLcZet6q+7UyieaxFqgpbxGBOZzZC7mlKj
RKDFZdVrE9gMv+zPvKT/MZtYHJouwHcnOC8DD5HN7hvq6HQ5fRdvpd2pIoAKIw9U
d+s8/rIPi2xnFetrF1A3qndHyGhRGqqhXdmff7PIAlZoimVRMXL3jyV+f/W0crDs
J5sq3uzcwqa5Q5ZU9fvRdHGeBVLJQeoej6vtN5uBKinHT9zlCaiJ8kTAt+N7kjz/
QahHh4vrsotBT70/IIIXNRaX5UFoIA9HWQEb84HJROcqj1qodvd3oIoZk18e4HIK
mg+1v0lKuBF9HLPYHjwqUMEgoiMlikCHcTqVUqNsyPRSNnTMz3aPISUwaGVIkVBQ
sQVllCOBEfKp2THbg3OrZfoMpp8nXlJMZBwhElDFUK8leDth8riB4WRw2pdJQYlT
nR1WMimCoUwKxMvsl9RA2O/oix7dmZiAzui3Fe7eoqxVkvL9jWlPXYi0f9acrJmz
uwq4Q/k5bt8WwI9uUlxe5SqR6LTUG0tVfZYk7RB7qZD+yPwwrXA0VLZ8PVm/yJ7j
Qxm6u41m9Ru67XBk49a3
=507s
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: Proposal for addition of distribution variables

[Mike Gilbert]

On Sun, Dec 4, 2016 at 6:31 PM, A. Wilcox  wrote:
> Roadmap
> - ---
>
> Since the shell environment is flexible, this change can be
> implemented almost immediately; the defaults specified in the Gentoo
> base profile ensure that at worst nothing will immediately change.  As
> forks, derivatives, and other organisations change the environment
> variables in their profiles or ``make.conf`` files, all updated
> ebuilds will immediately reflect the changes.
>
> During this, the variables can be added to the EAPI=7 specification,
> and may eventually be added to PMS §11.1.

It's not clear to me why this should be defined in PMS, especially if
this is going to be a profile variable in make.defaults.

I think we would only need to add it to PMS if you need to package
manager to compute the value based on the running system. Is that what
you had in mind here? If so, you will need to include that algorithm
in your patch.

Re: [gentoo-dev] RFC: Proposal for addition of distribution variables

[Brian Dolbec]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Sun, 4 Dec 2016 17:31:30 -0600
"A. Wilcox"  wrote:

> ===
> Proposal for addition of distribution variables
> ===
> 
> :Author:
>   A. Wilcox (Adélie Linux)
> :Date:
>   2016-12-04
> :Status:
>   Request for Comment
> 
> 
> 
> 
> Introduction
> - 
> 
> This proposal outlines the addition of environment variables to a
> future EAPI for the purposes of identifying the builder of packages,
> and a route for their more immediate addition to the Gentoo package
> tree before the next EAPI is published.
> 
> 
> Background
> - --
> 
> The Gentoo package repository is used not only by thousands of users,
> but also used by other distributions and organisations, such as
> Funtoo, CoreOS, and Google ChromeOS.  From the Gentoo Foundation's own
> charter, it self-describes in the following way: "Gentoo is a
> metadistribution".  That allows users to make their own flavours of
> Gentoo themselves.  Several forks already exist, including Exherbo,
> Funtoo, Sabayon, Galapagos, Vida, and Calculate.  Google also
> maintains a fork, ChromeOS, for their Chromebook laptops.  CoreOS also
> uses Gentoo's repository for their distribution.  In addition, there
> are also binary distributions such as Pentoo and Adélie that provide
> additional value but are not, in so many words, a 'fork' of Gentoo.
> 
> 
> Current Situation
> - -
> 
> Currently, forks and derivatives of Gentoo are required to choose one
> of only two options.  They can either use the tree as is, which causes
> packages to identify as being built for Gentoo and causes most
> autoconf -based packages (and some CMake packages in KDE) to have
> their bug report URLs to point to bugs.g.o.  Alternatively, they can
> fork the Git repository, requiring the need of manual merges when
> conflicts arise, and additional wasted effort when upstreams release
> new versions of software.
> 
> 
> Deficiencies
> - 
> 
> If a fork or derivative of Gentoo does not have the manpower or
> resources to modify all ebuilds that mention the Gentoo name / bug URL
> (about 1500 at my last count), then both distributions suffer.  Users
> of the fork will file bugs with Gentoo that are not bugs in Gentoo.
> Developers of the fork will not know about said bugs, and be unable to
> fix them.  Gentoo bug-wranglers and devs will have to waste time and
> resources testing bugs, finding out they are not even Gentoo bugs, and
> closing them as WONTFIX or WORKSFORME.
> 
> If they choose the alternative of forking the repository and changing
> these parameters in ebuilds, then it makes upstreaming their
> improvements much more difficult.  Sabayon has a repository on GitHub
> specifically for this, and Adélie wastes continual effort applying
> patches against the tree as it evolves.
> 
> 
> Solution Objectives
> - ---
> 
> * Protect Gentoo's name, trademark, and reputation by avoiding any
>   appearance that derivative distributions are associated with Gentoo.
> 
> * Lessen number of inappropriate bugs filed on bugs.g.o due to forks
> and derivatives.
> 
> * Foster better collaboration and sharing of improvements between
>   Gentoo and its forks/derivatives.
> 
> * Future potential changes to the bug report URL, while exceedingly
>   unlikely, is additionally made easier.
> 
> 
> Solution Vision
> - ---
> 
> I hereby propose adding the following two variables to the src_*
> phases.  None of these variables will have a default specified in PMS
> if they are added.
> 
> :``${DISTRO}``:
>   The name of the distribution.  This would be set in
>   ``profiles/base/make.defaults`` on Gentoo to "Gentoo".
> 
> :``${DISTRO_BUG_URL}``:
>   The URL to use to report bugs with software on the distribution.
>   This would be set to "https://bugs.gentoo.org/; on Gentoo.
> 
> By replacing references to 'Gentoo' passed to ./configure, make, etc
> with ``${DISTRO}``, distributions like Sabayon, Calculate, and Adélie
> will be able to notate their name as the distributor on packages.
> This will affect packages such as LibreOffice, OpenRC, X.Org, and KDE,
> which are all compiled with the name of the distribution internally.
> They use this for bug information, and having the proper distribution
> name will allow for more proper bug handling and ensure less
> inappropriate blame is assigned to Gentoo.  This also ensures that the
> fork or derivative's own mailing lists, forums, and so on are searched
> and contacted before Gentoo's.
> 
> By replacing references to 'bugs.gentoo.org' passed to ./configure
> with ``${DISTRO_BUG_URL}``, the Gentoo project will have a significant
> reduction in wasted effort handling inappropriately filed bugs when
> the issues are caused by changes by the forks and derivatives.
> 
> 
> Roadmap
> - ---
> 
> Since the shell environment is flexible, this 

[gentoo-dev] RFC: Proposal for addition of distribution variables

[A. Wilcox]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

===
Proposal for addition of distribution variables
===

:Author:
  A. Wilcox (Adélie Linux)
:Date:
  2016-12-04
:Status:
  Request for Comment




Introduction
- 

This proposal outlines the addition of environment variables to a
future EAPI for the purposes of identifying the builder of packages,
and a route for their more immediate addition to the Gentoo package
tree before the next EAPI is published.


Background
- --

The Gentoo package repository is used not only by thousands of users,
but also used by other distributions and organisations, such as
Funtoo, CoreOS, and Google ChromeOS.  From the Gentoo Foundation's own
charter, it self-describes in the following way: "Gentoo is a
metadistribution".  That allows users to make their own flavours of
Gentoo themselves.  Several forks already exist, including Exherbo,
Funtoo, Sabayon, Galapagos, Vida, and Calculate.  Google also
maintains a fork, ChromeOS, for their Chromebook laptops.  CoreOS also
uses Gentoo's repository for their distribution.  In addition, there
are also binary distributions such as Pentoo and Adélie that provide
additional value but are not, in so many words, a 'fork' of Gentoo.


Current Situation
- -

Currently, forks and derivatives of Gentoo are required to choose one
of only two options.  They can either use the tree as is, which causes
packages to identify as being built for Gentoo and causes most
autoconf -based packages (and some CMake packages in KDE) to have
their bug report URLs to point to bugs.g.o.  Alternatively, they can
fork the Git repository, requiring the need of manual merges when
conflicts arise, and additional wasted effort when upstreams release
new versions of software.


Deficiencies
- 

If a fork or derivative of Gentoo does not have the manpower or
resources to modify all ebuilds that mention the Gentoo name / bug URL
(about 1500 at my last count), then both distributions suffer.  Users
of the fork will file bugs with Gentoo that are not bugs in Gentoo.
Developers of the fork will not know about said bugs, and be unable to
fix them.  Gentoo bug-wranglers and devs will have to waste time and
resources testing bugs, finding out they are not even Gentoo bugs, and
closing them as WONTFIX or WORKSFORME.

If they choose the alternative of forking the repository and changing
these parameters in ebuilds, then it makes upstreaming their
improvements much more difficult.  Sabayon has a repository on GitHub
specifically for this, and Adélie wastes continual effort applying
patches against the tree as it evolves.


Solution Objectives
- ---

* Protect Gentoo's name, trademark, and reputation by avoiding any
  appearance that derivative distributions are associated with Gentoo.

* Lessen number of inappropriate bugs filed on bugs.g.o due to forks and
  derivatives.

* Foster better collaboration and sharing of improvements between
  Gentoo and its forks/derivatives.

* Future potential changes to the bug report URL, while exceedingly
  unlikely, is additionally made easier.


Solution Vision
- ---

I hereby propose adding the following two variables to the src_*
phases.  None of these variables will have a default specified in PMS
if they are added.

:``${DISTRO}``:
  The name of the distribution.  This would be set in
  ``profiles/base/make.defaults`` on Gentoo to "Gentoo".

:``${DISTRO_BUG_URL}``:
  The URL to use to report bugs with software on the distribution.
  This would be set to "https://bugs.gentoo.org/; on Gentoo.

By replacing references to 'Gentoo' passed to ./configure, make, etc
with ``${DISTRO}``, distributions like Sabayon, Calculate, and Adélie
will be able to notate their name as the distributor on packages.
This will affect packages such as LibreOffice, OpenRC, X.Org, and KDE,
which are all compiled with the name of the distribution internally.
They use this for bug information, and having the proper distribution
name will allow for more proper bug handling and ensure less
inappropriate blame is assigned to Gentoo.  This also ensures that the
fork or derivative's own mailing lists, forums, and so on are searched
and contacted before Gentoo's.

By replacing references to 'bugs.gentoo.org' passed to ./configure with
``${DISTRO_BUG_URL}``, the Gentoo project will have a significant
reduction in wasted effort handling inappropriately filed bugs when
the issues are caused by changes by the forks and derivatives.


Roadmap
- ---

Since the shell environment is flexible, this change can be
implemented almost immediately; the defaults specified in the Gentoo
base profile ensure that at worst nothing will immediately change.  As
forks, derivatives, and other organisations change the environment
variables in their profiles or ``make.conf`` files, all updated
ebuilds will immediately reflect the