Re: [gentoo-dev] [PATCH] use.desc: add global USE flag 'split-sbin'

[William Hubbs]

On Tue, Oct 15, 2019 at 11:08:14PM -0400, Joshua Kinard wrote:
> On 10/15/2019 13:34, David Seifert wrote:
> > On Tue, 2019-10-15 at 12:04 -0400, Mike Gilbert wrote:
> >> On Tue, Oct 15, 2019 at 12:02 PM Mike Gilbert 
> >> wrote:
> >>> On Tue, Oct 15, 2019 at 8:00 AM David Seifert 
> >>> wrote:
>  On Sun, 2019-10-13 at 12:33 -0400, Mike Gilbert wrote:
> > On Sat, Oct 12, 2019 at 1:52 PM David Seifert 
> > wrote:
> >> On Sat, 2019-10-12 at 19:01 +0200, Dennis Schridde wrote:
> >>> On Samstag, 12. Oktober 2019 18:02:28 CEST William Hubbs
> >>> wrote:
>  On Sat, Oct 12, 2019 at 01:11:49PM +0200, Michał Górny
>  wrote:
> > On Sat, 2019-10-12 at 13:00 +0200, David Seifert wrote:
> >> * Some distros have not just merged / and /usr, they
> >>
> >>   have also merged /usr/bin and /usr/sbin. By giving
> >>   users the choice of merging */bin and */sbin,
> >>   Gentoo follows suit.
> >
> > What about the scenario when /bin has been merged with
> > /usr/sbin
> > and /sbin with /usr/bin?  ;-P
> 
>  I also don't see the need for something like this. The
>  idea of
>  the
>  /usr
>  merge is to have all binaries available in one place, and
>  there
>  really
>  is not a good justification for separating bin from sbin.
> >>>
> >>> Do I read this correctly?  USE=-split-usr currently means
> >>> that
> >>> /bin,
> >>> /sbin, /
> >>> usr/bin and /usr/sbin point to the same directory?
> >>>
> >>> If that is not the case, then I agree that users should
> >>> have the
> >>> possibility
> >>> to set it up like this and USE=-split-sbin should be
> >>> supported.
> >>>
> >>> --Dennis
> >>
> >> I agree, I wasn't aware that USE=-split-usr implies the
> >> complete 2-
> >> level (/usr and *sbin) merge. In that case, all of this is
> >> obsolete.
> >
> > That was NOT my intention when I introduced the split-usr USE
> > flag.
> >
> > For bin/sbin, I would prefer to drop any conflicting links
> > unconditionally. Do you have examples of scenarios where this
> > is not
> > possible?
> >
> 
>  William has confirmed on IRC that USE=-split-usr performs the
>  complete
>  Fedora-esque /usr merge (which makes sense IMO).
> >>>
> >>> William's opinion is not the only one that matters.
> >>
> >> Sorry, I guess you are referring to the behavior baselayout? That
> >> doesn't necessarily align with the global usage.
> >>
> > 
> > https://gitweb.gentoo.org/proj/baselayout.git/tree/Makefile#n93
> > 
> > Clearly the usr-merge in baselayout intends to merge all these 4
> > directories. There is currently no option to merge /usr and / but keep
> > /bin and /sbin separate, so the most parsimonious solution here is to
> > assume that usr-merge semantics in Gentoo is about merging all 4
> > directories.
> 
> What is the source or origin point of the desire to merge /sbin into /bin?
> I know Fedora/RedHat championed the /usr/[s]bin into /[s]bin bit, but this
> is the first I've heard of trying to put all executables in one spot.  I
> have my doubts about such an idea, but want to see what the rationale is
> this time before writing the idea off to the funny farm.
> 
> My understanding for the separation was system binaries that only the
> superuser needs to touch go into /sbin and everything else into /bin.  This
> allowed for unpriv user PATHs to exclude /sbin (and in times antiquity, also
> exclude /usr/sbin).

Back in the day, the s in /sbin and /usr/sbin meant static, not super
user. All binaries in those directories were statically linked.

https://www.osnews.com/story/25556/understanding-the-bin-sbin-usrbin-usrsbin-split/
http://lists.busybox.net/pipermail/busybox/2010-December/074114.html

The tl;dr is that the meaning of /sbin and /usr/sbin was lost years ago.

William



signature.asc
Description: Digital signature

[gentoo-dev] RFC: GID assignment for gamemode

[Kai Krakow]

Resent because I used the wrong "From:"...

Am Mo., 14. Okt. 2019 um 10:13 Uhr schrieb Kai Krakow :
>
> I would like to reserve GID 405 for games-util/gamemode.
>
> As far as I can tell, GID 405 is free [1]
>
> Here's a PR for this change [2]
>
> [1] https://api.gentoo.org/uid-gid.txt
> [2] https://github.com/gentoo/gentoo/pull/13158

Re: [gentoo-dev] [PATCH] use.desc: add global USE flag 'split-sbin'

[William Hubbs]

On Wed, Oct 16, 2019 at 07:17:09PM +0200, Ulrich Mueller wrote:
> > On Wed, 16 Oct 2019, William Hubbs wrote:
> 
> > Back in the day, the s in /sbin and /usr/sbin meant static, not super
> > user. All binaries in those directories were statically linked.
> 
> Where have you found that statement? The "s" stands for "system",
> not for "static". See for example [1].
> 
> Traditionally, these programs used to be in /etc (!), and were moved
> to /sbin later. For example, documentation of V7 Unix [2] says that
> "dangerous maintenance utilities" live in /etc (and doesn't mention
> /sbin at all).
> 
> Somewhat later, in 4.3BSD NET/2 these system binaries are in /sbin:
> "system programs and administration utilities fundamental to both
> single-user and multi-user environments" [3].
> 
> 
> [1] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s16.html

> [2] 
> https://www.freebsd.org/cgi/man.cgi?query=hier=0=0=Unix+Seventh+Edition=default=html
> [3] 
> https://www.freebsd.org/cgi/man.cgi?query=hier=0=0=4.3BSD+NET%2F2=default=html

Please read the links I posted before --specifically the comments
from Rob.

Also, there is this.

https://news.ycombinator.com/item?id=3519952

Tl;dr the bin sbin separation is a historical separation that doesn't
make sense any longer.

William

> <




signature.asc
Description: Digital signature

Re: [gentoo-dev] The demotivating process of contributing to devmanual

[Ulrich Mueller]

> On Tue, 15 Oct 2019, Michał Górny wrote:

> On Tue, 2019-10-15 at 16:47 -0400, Mike Gilbert wrote:
>> Maybe you should join the project? Especially if you are making major
>> contributions.

> Are you suggesting that I join the project and start committing
> without review, or disregarding review?  I have serious doubts on
> joining the project if I am repeatedly proven to be doing things wrong
> -- whether the issues were serious or not.

Joining the project won't prevent you from asking for review. :)

And if you don't get any reply after waiting for a few days, simply push
your commits. Mistakes in the documentation don't cause any immediate
breakage, and can be corrected later.

Ulrich


signature.asc
Description: PGP signature

[gentoo-dev] [RFC] Getting rid of EAPI 0 by the end of 2019

[Michał Górny]

Hi,

We have <438 EAPI 0 ebuilds left (I've removed a few more since [1]). 
We're nearing the time when we can finally get rid of EAPI 0.  For this
reason, I'd like to set a 'media goal' of getting EAPI 0 by the end
of 2019.

Why getting rid of EAPI 0 is important?  Because there's a huge leap
between EAPI 0 and EAPI 4+ (though 4 is also close to being gone). 
Removing EAPI 0 means we can finally start cleaning up eclasses
and documentation.  Just to name a few things, we're finally going
to have consistent '||die' in helpers, phase function set, USE flag
dependencies, no implicit RDEPEND...  Just take a look at [2],
and you're going to be surprised how many things have changed.

What's been done?  I've taken care of cleaning up old versions
and requesting stabilization of newer ones whenever feasible.
I've treecleaned a lot of dead packages (and a few of them have been
revived and updated).  I've filed bugs for probably all the packages
left and collected them on the tracker [3].

What needs to be done?  The maintainers need to port remaining packages
or send last rites for them.  Some of those packages are not being cared
by the maintainers anymore, so if you see something valuable, take it. 
If you see something obviously dead, let treecleaners know.  Any and all
help will be appreciated!

The rough plan is to have a clear vision of what to do with
the remaining packages one month from now -- either have them bumped
to a newer EAPI and waiting for stabilization, or last rited for removal
in mid-December.

[1] https://qa-reports.gentoo.org/output/eapi_usage.txt
[2] https://projects.gentoo.org/pms/7/pms.html#x1-172000E
[3] https://bugs.gentoo.org/657150

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [PATCH] use.desc: add global USE flag 'split-sbin'

[Jaco Kroon]

Hi,

On 2019/10/15 19:34, David Seifert wrote:
> On Tue, 2019-10-15 at 12:04 -0400, Mike Gilbert wrote:
>> On Tue, Oct 15, 2019 at 12:02 PM Mike Gilbert 
>> wrote:
>>> On Tue, Oct 15, 2019 at 8:00 AM David Seifert 
>>> wrote:
 On Sun, 2019-10-13 at 12:33 -0400, Mike Gilbert wrote:
> On Sat, Oct 12, 2019 at 1:52 PM David Seifert 
> wrote:
>> On Sat, 2019-10-12 at 19:01 +0200, Dennis Schridde wrote:
>>> On Samstag, 12. Oktober 2019 18:02:28 CEST William Hubbs
>>> wrote:
 On Sat, Oct 12, 2019 at 01:11:49PM +0200, Michał Górny
 wrote:
> On Sat, 2019-10-12 at 13:00 +0200, David Seifert wrote:
>> * Some distros have not just merged / and /usr, they
>>
>>   have also merged /usr/bin and /usr/sbin. By giving
>>   users the choice of merging */bin and */sbin,
>>   Gentoo follows suit.
> What about the scenario when /bin has been merged with
> /usr/sbin
> and /sbin with /usr/bin?  ;-P
 I also don't see the need for something like this. The
 idea of
 the
 /usr
 merge is to have all binaries available in one place, and
 there
 really
 is not a good justification for separating bin from sbin.
>>> Do I read this correctly?  USE=-split-usr currently means
>>> that
>>> /bin,
>>> /sbin, /
>>> usr/bin and /usr/sbin point to the same directory?
>>>
>>> If that is not the case, then I agree that users should
>>> have the
>>> possibility
>>> to set it up like this and USE=-split-sbin should be
>>> supported.
>>>
>>> --Dennis
>> I agree, I wasn't aware that USE=-split-usr implies the
>> complete 2-
>> level (/usr and *sbin) merge. In that case, all of this is
>> obsolete.
> That was NOT my intention when I introduced the split-usr USE
> flag.
>
> For bin/sbin, I would prefer to drop any conflicting links
> unconditionally. Do you have examples of scenarios where this
> is not
> possible?
>
 William has confirmed on IRC that USE=-split-usr performs the
 complete
 Fedora-esque /usr merge (which makes sense IMO).
>>> William's opinion is not the only one that matters.
>> Sorry, I guess you are referring to the behavior baselayout? That
>> doesn't necessarily align with the global usage.
>>
> https://gitweb.gentoo.org/proj/baselayout.git/tree/Makefile#n93
>
> Clearly the usr-merge in baselayout intends to merge all these 4
> directories. There is currently no option to merge /usr and / but keep
> /bin and /sbin separate, so the most parsimonious solution here is to
> assume that usr-merge semantics in Gentoo is about merging all 4
> directories.
>
>
For what it's worth.  All of my systems are installed with a fixed-size
512MB / with everything else (including /usr) on separate LVs.

Whilst sbin vs bin is just a matter of what's available, to me it makes
sense to keep these split.  To me it's always been logical to keep
administrative type (root) tools under sbin, and stuff that's generally
useful for users under bin.

Keeping / and /usr split (or the ability to keep it split) is rather
crucial for me.  It's for historic installations a matter of space
constraints on /.  For new installations it's a matter of keeping / as
small as possible in order to have a smallish bootable system which can
be used for recovering the rest of the system, ideally without an initrd
(which also works to an extent).

Kind Regards,
Jaco

Re: [gentoo-dev] [PATCH v2] font.eclass: Port to EAPI-7

[Michał Górny]

On Wed, 2019-10-16 at 00:05 +0200, Andreas Sturmlechner wrote:
> (ignore previous mail, this time hopefully not scrambled)
> 
> --- a/eclass/font.eclass
> +++ b/eclass/font.eclass
> @@ -4,16 +4,15 @@
>  # @ECLASS: font.eclass
>  # @MAINTAINER:
>  # fo...@gentoo.org
> -# @SUPPORTED_EAPIS: 0 1 2 3 4 5 6
> +# @SUPPORTED_EAPIS: 0 1 2 3 4 5 6 7
>  # @BLURB: Eclass to make font installation uniform
> 

LGTM.  Good work.  Please merge it, and start killing EAPI 0 ;-).

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [PATCH] use.desc: add global USE flag 'split-sbin'

[David Seifert]

On Wed, 2019-10-16 at 11:18 +0200, Jaco Kroon wrote:
> Hi,
> 
> On 2019/10/15 19:34, David Seifert wrote:
> > On Tue, 2019-10-15 at 12:04 -0400, Mike Gilbert wrote:
> > > On Tue, Oct 15, 2019 at 12:02 PM Mike Gilbert  > > >
> > > wrote:
> > > > On Tue, Oct 15, 2019 at 8:00 AM David Seifert 
> > > > wrote:
> > > > > On Sun, 2019-10-13 at 12:33 -0400, Mike Gilbert wrote:
> > > > > > On Sat, Oct 12, 2019 at 1:52 PM David Seifert <
> > > > > > s...@gentoo.org>
> > > > > > wrote:
> > > > > > > On Sat, 2019-10-12 at 19:01 +0200, Dennis Schridde wrote:
> > > > > > > > On Samstag, 12. Oktober 2019 18:02:28 CEST William
> > > > > > > > Hubbs
> > > > > > > > wrote:
> > > > > > > > > On Sat, Oct 12, 2019 at 01:11:49PM +0200, Michał
> > > > > > > > > Górny
> > > > > > > > > wrote:
> > > > > > > > > > On Sat, 2019-10-12 at 13:00 +0200, David Seifert
> > > > > > > > > > wrote:
> > > > > > > > > > > * Some distros have not just merged / and /usr,
> > > > > > > > > > > they
> > > > > > > > > > > 
> > > > > > > > > > >   have also merged /usr/bin and /usr/sbin. By
> > > > > > > > > > > giving
> > > > > > > > > > >   users the choice of merging */bin and */sbin,
> > > > > > > > > > >   Gentoo follows suit.
> > > > > > > > > > What about the scenario when /bin has been merged
> > > > > > > > > > with
> > > > > > > > > > /usr/sbin
> > > > > > > > > > and /sbin with /usr/bin?  ;-P
> > > > > > > > > I also don't see the need for something like this.
> > > > > > > > > The
> > > > > > > > > idea of
> > > > > > > > > the
> > > > > > > > > /usr
> > > > > > > > > merge is to have all binaries available in one place,
> > > > > > > > > and
> > > > > > > > > there
> > > > > > > > > really
> > > > > > > > > is not a good justification for separating bin from
> > > > > > > > > sbin.
> > > > > > > > Do I read this correctly?  USE=-split-usr currently
> > > > > > > > means
> > > > > > > > that
> > > > > > > > /bin,
> > > > > > > > /sbin, /
> > > > > > > > usr/bin and /usr/sbin point to the same directory?
> > > > > > > > 
> > > > > > > > If that is not the case, then I agree that users should
> > > > > > > > have the
> > > > > > > > possibility
> > > > > > > > to set it up like this and USE=-split-sbin should be
> > > > > > > > supported.
> > > > > > > > 
> > > > > > > > --Dennis
> > > > > > > I agree, I wasn't aware that USE=-split-usr implies the
> > > > > > > complete 2-
> > > > > > > level (/usr and *sbin) merge. In that case, all of this
> > > > > > > is
> > > > > > > obsolete.
> > > > > > That was NOT my intention when I introduced the split-usr
> > > > > > USE
> > > > > > flag.
> > > > > > 
> > > > > > For bin/sbin, I would prefer to drop any conflicting links
> > > > > > unconditionally. Do you have examples of scenarios where
> > > > > > this
> > > > > > is not
> > > > > > possible?
> > > > > > 
> > > > > William has confirmed on IRC that USE=-split-usr performs the
> > > > > complete
> > > > > Fedora-esque /usr merge (which makes sense IMO).
> > > > William's opinion is not the only one that matters.
> > > Sorry, I guess you are referring to the behavior baselayout? That
> > > doesn't necessarily align with the global usage.
> > > 
> > https://gitweb.gentoo.org/proj/baselayout.git/tree/Makefile#n93
> > 
> > Clearly the usr-merge in baselayout intends to merge all these 4
> > directories. There is currently no option to merge /usr and / but
> > keep
> > /bin and /sbin separate, so the most parsimonious solution here is
> > to
> > assume that usr-merge semantics in Gentoo is about merging all 4
> > directories.
> > 
> > 
> For what it's worth.  All of my systems are installed with a fixed-
> size
> 512MB / with everything else (including /usr) on separate LVs.
> 
> Whilst sbin vs bin is just a matter of what's available, to me it
> makes
> sense to keep these split.  To me it's always been logical to keep
> administrative type (root) tools under sbin, and stuff that's
> generally
> useful for users under bin.
> 
> Keeping / and /usr split (or the ability to keep it split) is rather
> crucial for me.  It's for historic installations a matter of space
> constraints on /.  For new installations it's a matter of keeping /
> as
> small as possible in order to have a smallish bootable system which
> can
> be used for recovering the rest of the system, ideally without an
> initrd
> (which also works to an extent).
> 
> Kind Regards,
> Jaco
> 

For the umpteenth time time: nothing will change. You can keep your
(albeit broken) separate / and /usr partitions. *NOTHING* will change
for anyone. There are no plans to change the defaults. This is *MERELY*
about giving people the chance to opt in to the /usr-merge.

That said, the idea of using / as a "recovery" filesystem in general is
broken: 
https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/
And no, this is not systemd breaking your system, or Lennart, it's
distros and userlands not being careful to have things in / never
depend on things in /usr.

[gentoo-dev] [PATCH 1/2] kde.org.eclass: New eclass, split from kde5.eclass

[Andreas Sturmlechner]

Right now we have kde5.eclass and kde5-functions.eclass, with their structure 
carried over from kde4*eclass times, but the lines were blurred somewhat when 
minimum version requirements for the main KDE products were moved into 
kde5-functions.eclass at some point. Direct usage of kde5-functions.eclass was 
always minimal and is zero at this point.

kde5.eclass already has KDE_AUTODEPS variable to enable use of it without 
inheriting build system and common dependencies (but still inheriting 
cmake-utils.eclass). The new eclass will start to break up that joint and 
contain only code to fetch releases or from git for projects hosted on kde.org 
infrastructure, without making assumptions about a build system, and carry over 
some general meta variables.

Going forward, the useful bits that remain from kde5{,-functions}.eclass will 
be absorbed into a new, more general purpose eclass that aims to be of service 
to non-KDE packages using ECM (and KDE Frameworks) as well.

tl;dr:
- pkg_nofetch and src_unpack move from kde5.eclass to kde.org.eclass
- kde5.eclass inherits kde.org.eclass
- ebuilds using kde5.eclass w/ KDE_AUTODEPS=false will only inherit kde.org
- more good things to come


--- /dev/null
+++ b/eclass/kde.org.eclass
@@ -0,0 +1,241 @@
+# Copyright 1999-2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: kde.org.eclass
+# @MAINTAINER:
+# k...@gentoo.org
+# @SUPPORTED_EAPIS: 7
+# @BLURB: Support eclass for packages that are hosted on kde.org 
infrastructure.
+# @DESCRIPTION:
+# This eclass is mainly providing facilities for the upstream release groups
+# Frameworks, Plasma, Applications to assemble default SRC_URI for tarballs,
+# set up git-r3.eclass for stable/master branch versions or restrict access to
+# unreleased (packager access only) tarballs in Gentoo KDE overlay, but it may
+# be also used by any other package hosted on kde.org.
+# It also contains default meta variables for settings not specific to any
+# particular build system.
+
+if [[ -z ${_KDE_ORG_ECLASS} ]]; then
+_KDE_ORG_ECLASS=1
+
+# @ECLASS-VARIABLE: KDE_BUILD_TYPE
+# @DESCRIPTION:
+# If PV matches "**", this is automatically set to "live".
+# Otherwise, this is automatically set to "release".
+KDE_BUILD_TYPE="release"
+if [[ ${PV} = ** ]]; then
+   KDE_BUILD_TYPE="live"
+fi
+export KDE_BUILD_TYPE
+
+if [[ ${KDE_BUILD_TYPE} = live ]]; then
+   inherit git-r3
+fi
+
+EXPORT_FUNCTIONS pkg_nofetch src_unpack
+
+# @ECLASS-VARIABLE: KDE_ORG_NAME
+# @DESCRIPTION:
+# If unset, default value is set to ${PN}.
+# Name of the package as hosted on kde.org mirrors.
+: ${KDE_ORG_NAME:=$PN}
+
+# @ECLASS-VARIABLE: KDE_SELINUX_MODULE
+# @DESCRIPTION:
+# If set to "none", do nothing.
+# For any other value, add selinux to IUSE, and depending on that useflag
+# add a dependency on sec-policy/selinux-${KDE_SELINUX_MODULE} to (R)DEPEND.
+: ${KDE_SELINUX_MODULE:=none}
+
+case ${KDE_SELINUX_MODULE} in
+   none)   ;;
+   *)
+   IUSE+=" selinux"
+   RDEPEND+=" selinux? ( sec-policy/selinux-${KDE_SELINUX_MODULE} 
)"
+   ;;
+esac
+
+if [[ ${CATEGORY} = kde-frameworks ]]; then
+   SLOT=5/${PV}
+   [[ ${KDE_BUILD_TYPE} = release ]] && SLOT=$(ver_cut 1)/$(ver_cut 1-2)
+fi
+
+# @ECLASS-VARIABLE: KDE_UNRELEASED
+# @INTERNAL
+# @DESCRIPTION
+# An array of $CATEGORY-$PV pairs of packages that are unreleased upstream.
+# Any package matching this will have fetch restriction enabled, and receive
+# a proper error message via pkg_nofetch.
+KDE_UNRELEASED=( )
+
+HOMEPAGE="https://kde.org/;
+
+_kde_is_unreleased() {
+   local pair
+   for pair in "${KDE_UNRELEASED[@]}" ; do
+   if [[ "${pair}" = "${CATEGORY}-${PV}" ]]; then
+   return 0
+   fi
+   done
+
+   return 1
+}
+
+# Determine fetch location for released tarballs
+_calculate_src_uri() {
+   debug-print-function ${FUNCNAME} "$@"
+
+   local _src_uri="mirror://kde/"
+
+   case ${CATEGORY} in
+   kde-apps)
+   case ${PV} in
+   ??.??.[6-9]? )
+   
_src_uri+="unstable/applications/${PV}/src/"
+   RESTRICT+=" mirror"
+   ;;
+   *) _src_uri+="stable/applications/${PV}/src/" ;;
+   esac
+   ;;
+   kde-frameworks)
+   _src_uri+="stable/frameworks/$(ver_cut 1-2)/"
+   case ${PN} in
+   kdelibs4support | \
+   kdewebkit | \
+   khtml | \
+   kjs | \
+   kjsembed | \
+   kmediaplayer | \
+   kross)
+   

Re: [gentoo-dev] [PATCH] use.desc: add global USE flag 'split-sbin'

[Jaco Kroon]

Hi,

-- large trim --
>> For what it's worth.  All of my systems are installed with a fixed-
>> size
>> 512MB / with everything else (including /usr) on separate LVs.
>>
>> Whilst sbin vs bin is just a matter of what's available, to me it
>> makes
>> sense to keep these split.  To me it's always been logical to keep
>> administrative type (root) tools under sbin, and stuff that's
>> generally
>> useful for users under bin.
>>
>> Keeping / and /usr split (or the ability to keep it split) is rather
>> crucial for me.  It's for historic installations a matter of space
>> constraints on /.  For new installations it's a matter of keeping /
>> as
>> small as possible in order to have a smallish bootable system which
>> can
>> be used for recovering the rest of the system, ideally without an
>> initrd
>> (which also works to an extent).
>>
>> Kind Regards,
>> Jaco
>>
> For the umpteenth time time: nothing will change. You can keep your
> (albeit broken) separate / and /usr partitions. *NOTHING* will change
> for anyone. There are no plans to change the defaults. This is *MERELY*
> about giving people the chance to opt in to the /usr-merge.
Thanks for the confirmation.  As long as it's an OPTION I'm happy.  And
no, other than on my desktop machine a split /usr is working very well,
and even in that case a split off /lib/firmware actually caused me much,
much more problems (for i915 and amdgpu firmware) than a split /usr. 
Unfortunately /lib/firmware grew over the years and so I had no choice
other than to split it off after the fact.
>
> That said, the idea of using / as a "recovery" filesystem in general is
> broken: 
> https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/
> And no, this is not systemd breaking your system, or Lennart, it's
> distros and userlands not being careful to have things in / never
> depend on things in /usr.

It's saved my butt more than once when the (extremely) limited tools in
the initrds on those same systems failed to do so.  Mostly these cases
weren't Gentoo.  Yes RHEL, I'm looking at you.  Gentoo I generally
recover crazy faults without the use of system rescue CDs (probably
required it 10 times over 15 years).  Can't say the same for those
distro's pushing for "recovery systems in initrd", and I'm running
probably 3x more Gentoo systems than all other distro's combined.

The only stuff so far I really wished worked without /usr was editors
such as vim and/or nano (sed sufficed in those cases).

Would contributing a script that's able to check which binaries in /bin
(and /sbin) depend on libs not also on / be useful here?  Perhaps as a
QA check somehow?

And I get that that's a completely different rabbit hole ...

1.  What about non-lib files, eg, /usr/share/zoneinfo?
2.  Should such binaries be moved to /usr or should the libraries be
moved to /?
X.  a gazillion things I haven't even started to think about.

Kind Regards,
Jaco


>
>

Re: [gentoo-dev] [PATCH] use.desc: add global USE flag 'split-sbin'

[Michał Górny]

On Wed, 2019-10-16 at 12:03 +0200, Jaco Kroon wrote:
> Hi,
> 
> -- large trim --
> > > For what it's worth.  All of my systems are installed with a fixed-
> > > size
> > > 512MB / with everything else (including /usr) on separate LVs.
> > > 
> > > Whilst sbin vs bin is just a matter of what's available, to me it
> > > makes
> > > sense to keep these split.  To me it's always been logical to keep
> > > administrative type (root) tools under sbin, and stuff that's
> > > generally
> > > useful for users under bin.
> > > 
> > > Keeping / and /usr split (or the ability to keep it split) is rather
> > > crucial for me.  It's for historic installations a matter of space
> > > constraints on /.  For new installations it's a matter of keeping /
> > > as
> > > small as possible in order to have a smallish bootable system which
> > > can
> > > be used for recovering the rest of the system, ideally without an
> > > initrd
> > > (which also works to an extent).
> > > 
> > > Kind Regards,
> > > Jaco
> > > 
> > For the umpteenth time time: nothing will change. You can keep your
> > (albeit broken) separate / and /usr partitions. *NOTHING* will change
> > for anyone. There are no plans to change the defaults. This is *MERELY*
> > about giving people the chance to opt in to the /usr-merge.
> Thanks for the confirmation.  As long as it's an OPTION I'm happy.  And
> no, other than on my desktop machine a split /usr is working very well,
> and even in that case a split off /lib/firmware actually caused me much,
> much more problems (for i915 and amdgpu firmware) than a split /usr. 
> Unfortunately /lib/firmware grew over the years and so I had no choice
> other than to split it off after the fact.
> > That said, the idea of using / as a "recovery" filesystem in general is
> > broken: 
> > https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/
> > And no, this is not systemd breaking your system, or Lennart, it's
> > distros and userlands not being careful to have things in / never
> > depend on things in /usr.
> 
> It's saved my butt more than once when the (extremely) limited tools in
> the initrds on those same systems failed to do so.  Mostly these cases
> weren't Gentoo.  Yes RHEL, I'm looking at you.  Gentoo I generally
> recover crazy faults without the use of system rescue CDs (probably
> required it 10 times over 15 years).  Can't say the same for those
> distro's pushing for "recovery systems in initrd", and I'm running
> probably 3x more Gentoo systems than all other distro's combined.
> 
> The only stuff so far I really wished worked without /usr was editors
> such as vim and/or nano (sed sufficed in those cases).
> 
> Would contributing a script that's able to check which binaries in /bin
> (and /sbin) depend on libs not also on / be useful here?  Perhaps as a
> QA check somehow?
> 

I've been doing that for quite some time, and the usual answer was 'I
don't care, use initramfs, but I WON'T move files correctly to /usr'.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part

[gentoo-dev] [PATCH 2/2] kde5.eclass: Inherit kde.org.eclass and drop moved functions/vars

[Andreas Sturmlechner]

Functions moved to kde.org:
- _kde_is_unreleased
- _calculate_src_uri
- _calculate_live_repo
- kde5_pkg_nofetch
- kde5_src_unpack

Variables moved to kde.org:
- KDE_BUILD_TYPE
- KDE_SELINUX_MODULE
- KDE_UNRELEASED
- HOMEPAGE

Variables deprecated:
- KDE_SUBSLOT (define SLOT in ebuild)
- KMNAME (use KDE_ORG_NAME in kde.org.eclass instead)

--- a/eclass/kde5.eclass
+++ b/eclass/kde5.eclass
@@ -25,6 +25,12 @@
 if [[ -z ${_KDE5_ECLASS} ]]; then
 _KDE5_ECLASS=1
 
+# Propagate KMNAME to kde.org.eclass
+# PORTING: Use KDE_ORG_NAME from kde.org.eclass instead
+if [[ -z ${KDE_ORG_NAME} ]]; then
+   KDE_ORG_NAME=${KMNAME:=$PN}
+fi
+
 # @ECLASS-VARIABLE: VIRTUALX_REQUIRED
 # @DESCRIPTION:
 # For proper description see virtualx.eclass manpage.
@@ -32,17 +38,13 @@ _KDE5_ECLASS=1
 # for tests you should proceed with setting VIRTUALX_REQUIRED=test.
 : ${VIRTUALX_REQUIRED:=manual}
 
-inherit cmake-utils flag-o-matic kde5-functions virtualx xdg
-
-if [[ ${KDE_BUILD_TYPE} = live ]]; then
-   inherit git-r3
-fi
+inherit cmake-utils flag-o-matic kde.org kde5-functions virtualx xdg
 
 if [[ -v KDE_GCC_MINIMAL ]]; then
EXPORT_FUNCTIONS pkg_pretend
 fi
 
-EXPORT_FUNCTIONS pkg_setup pkg_nofetch src_unpack src_prepare src_configure 
src_compile src_test src_install pkg_preinst pkg_postinst pkg_postrm
+EXPORT_FUNCTIONS pkg_setup src_prepare src_configure src_compile src_test 
src_install pkg_preinst pkg_postinst pkg_postrm
 
 # @ECLASS-VARIABLE: ECM_KDEINSTALLDIRS
 # @DESCRIPTION:
@@ -127,37 +129,19 @@ if [[ ${CATEGORY} = kde-frameworks ]]; then
 fi
 : ${KDE_TEST:=false}
 
-# @ECLASS-VARIABLE: KDE_SELINUX_MODULE
-# @DESCRIPTION:
-# If set to "none", do nothing.
-# For any other value, add selinux to IUSE, and depending on that useflag
-# add a dependency on sec-policy/selinux-${KDE_SELINUX_MODULE} to (R)DEPEND.
-: ${KDE_SELINUX_MODULE:=none}
-
 # @ECLASS-VARIABLE: KDE_SUBSLOT
 # @DESCRIPTION:
 # If set to "false", do nothing.
 # If set to "true", add a subslot to the package, where subslot is either
 # defined as major.minor version for kde-*/ categories or ${PV} if other.
 # For any other value, that value will be used as subslot.
+# PORTING: no replacement, define in ebuild
 : ${KDE_SUBSLOT:=false}
 
-# @ECLASS-VARIABLE: KDE_UNRELEASED
-# @INTERNAL
-# @DESCRIPTION
-# An array of $CATEGORY-$PV pairs of packages that are unreleased upstream.
-# Any package matching this will have fetch restriction enabled, and receive
-# a proper error message via pkg_nofetch.
-KDE_UNRELEASED=( )
-
-HOMEPAGE="https://kde.org/;
+# PORTING: LICENSE no longer set by eclass, define in ebuild
 LICENSE="GPL-2"
-
-SLOT=5
-
-if [[ ${CATEGORY} = kde-frameworks ]]; then
-   KDE_SUBSLOT=true
-fi
+# PORTING: SLOT no longer set by eclass except for kde-frameworks
+[[ ${CATEGORY} = kde-frameworks ]] || SLOT=5
 
 case ${KDE_SUBSLOT} in
false)  ;;
@@ -245,154 +229,10 @@ case ${KDE_TEST} in
;;
 esac
 
-case ${KDE_SELINUX_MODULE} in
-   none)   ;;
-   *)
-   IUSE+=" selinux"
-   RDEPEND+=" selinux? ( sec-policy/selinux-${KDE_SELINUX_MODULE} 
)"
-   ;;
-esac
-
 DEPEND+=" ${COMMONDEPEND}"
 RDEPEND+=" ${COMMONDEPEND}"
 unset COMMONDEPEND
 
-if [[ -n ${KMNAME} && ${KMNAME} != ${PN} && ${KDE_BUILD_TYPE} = release ]]; 
then
-   S=${WORKDIR}/${KMNAME}-${PV}
-fi
-
-_kde_is_unreleased() {
-   local pair
-   for pair in "${KDE_UNRELEASED[@]}" ; do
-   if [[ "${pair}" = "${CATEGORY}-${PV}" ]]; then
-   return 0
-   fi
-   done
-
-   return 1
-}
-
-# Determine fetch location for released tarballs
-_calculate_src_uri() {
-   debug-print-function ${FUNCNAME} "$@"
-
-   local _kmname
-
-   if [[ -n ${KMNAME} ]]; then
-   _kmname=${KMNAME}
-   else
-   _kmname=${PN}
-   fi
-
-   case ${PN} in
-   kdelibs4support | \
-   kdewebkit | \
-   khtml | \
-   kjs | \
-   kjsembed | \
-   kmediaplayer | \
-   kross)
-   _kmname="portingAids/${_kmname}"
-   ;;
-   kdesignerplugin)
-   [[ ${PV} = 5.6[01].* ]] || 
_kmname="portingAids/${_kmname}"
-   ;;
-   esac
-
-   case ${CATEGORY} in
-   kde-apps)
-   case ${PV} in
-   ??.?.[6-9]? | ??.??.[6-9]? )
-   
SRC_URI="mirror://kde/unstable/applications/$
{PV}/src/${_kmname}-${PV}.tar.xz"
-   RESTRICT+=" mirror"
-   ;;
-   *)
-   
SRC_URI="mirror://kde/stable/applications/${PV}/
src/${_kmname}-${PV}.tar.xz" ;;
-   esac
-   ;;
-   kde-frameworks)
-   

Re: [gentoo-dev] [PATCH] use.desc: add global USE flag 'split-sbin'

[Ulrich Mueller]

> On Wed, 16 Oct 2019, William Hubbs wrote:

> Back in the day, the s in /sbin and /usr/sbin meant static, not super
> user. All binaries in those directories were statically linked.

Where have you found that statement? The "s" stands for "system",
not for "static". See for example [1].

Traditionally, these programs used to be in /etc (!), and were moved
to /sbin later. For example, documentation of V7 Unix [2] says that
"dangerous maintenance utilities" live in /etc (and doesn't mention
/sbin at all).

Somewhat later, in 4.3BSD NET/2 these system binaries are in /sbin:
"system programs and administration utilities fundamental to both
single-user and multi-user environments" [3].


[1] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s16.html
[2] 
https://www.freebsd.org/cgi/man.cgi?query=hier=0=0=Unix+Seventh+Edition=default=html
[3] 
https://www.freebsd.org/cgi/man.cgi?query=hier=0=0=4.3BSD+NET%2F2=default=html
<


signature.asc
Description: PGP signature

Re: [gentoo-dev] [PATCH] use.desc: add global USE flag 'split-sbin'

[William Hubbs]

Hi Jaco,

On Wed, Oct 16, 2019 at 11:18:38AM +0200, Jaco Kroon wrote:
> Hi,
 
 *snip*

> For what it's worth.  All of my systems are installed with a fixed-size
> 512MB / with everything else (including /usr) on separate LVs.
> 
> Whilst sbin vs bin is just a matter of what's available, to me it makes
> sense to keep these split.  To me it's always been logical to keep
> administrative type (root) tools under sbin, and stuff that's generally
> useful for users under bin.
 
 As I said in my previous message, sbin and /usr/sbin are supposed to
 have statically linked binaries in them, "s" means static not
 superuser.

> Keeping / and /usr split (or the ability to keep it split) is rather
> crucial for me.  It's for historic installations a matter of space
> constraints on /.  For new installations it's a matter of keeping / as
> small as possible in order to have a smallish bootable system which can
> be used for recovering the rest of the system, ideally without an initrd
> (which also works to an extent).

Having / and /usr on separate filesystems is not what split-usr is
about. split-usr just means that /bin /lib* and /sbin are directories
not symlinks.
 
 Splitting / and /usr to separate filesystems without an initramfs is
 not officially supported.

 William


signature.asc
Description: Digital signature