Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Is Profile 17.1 a move toward a Linux monoculture?
View unanswered posts
View posts from last 24 hours

Goto page 1, 2, 3  Next  
Reply to topic    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  
Author Message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6920

PostPosted: Tue Jul 23, 2019 3:57 pm    Post subject: Is Profile 17.1 a move toward a Linux monoculture? Reply with quote

Split from Gentoo seems to be chasing nu Linux design (/usr merge) as both threads warrant seprate discussions. --pjp

pjp wrote:
:( Then it is a general problem within the Linux ecosystem. Which would appear to be an effort to achieve monoculture, with the vulnerabilities and risks of catastrophic failure associated with it. I'm not a marketer, so I'm sure they'd use different messaging.

Profile 17.1 is already an explicit move toward such a monoculture, and yes, the end state is going to be one where upstreams don't even make a token effort to support anything but The RedHat/Canonical(*delete as appropriate) FHS instead of a well-thought-out one.
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6148
Location: Dallas area

PostPosted: Tue Jul 23, 2019 4:18 pm    Post subject: Reply with quote

Ant P. wrote:
pjp wrote:
:( Then it is a general problem within the Linux ecosystem. Which would appear to be an effort to achieve monoculture, with the vulnerabilities and risks of catastrophic failure associated with it. I'm not a marketer, so I'm sure they'd use different messaging.

Profile 17.1 is already an explicit move toward such a monoculture, and yes, the end state is going to be one where upstreams don't even make a token effort to support anything but The RedHat/Canonical(*delete as appropriate) FHS instead of a well-thought-out one.


++ on both posts

Edit to add: I was on no-multilib so the switch to 17.1 wouldn't have been terribly hard, but I modified it anyway because I didn't want to recompile things just because. I even left */lib linked to */lib64 and just removed the check for them being linked (some funky bash script :roll: does the check on emerge).
Works perfectly well, though I suppose I could have just left it on profile 17.0 too.
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
Gatsby
Tux's lil' helper
Tux's lil' helper


Joined: 18 Jan 2010
Posts: 121
Location: 127.0.0.1

PostPosted: Tue Jul 23, 2019 6:17 pm    Post subject: Reply with quote

Ant P. wrote:
pjp wrote:
:( Then it is a general problem within the Linux ecosystem. Which would appear to be an effort to achieve monoculture, with the vulnerabilities and risks of catastrophic failure associated with it. I'm not a marketer, so I'm sure they'd use different messaging.

Profile 17.1 is already an explicit move toward such a monoculture, and yes, the end state is going to be one where upstreams don't even make a token effort to support anything but The RedHat/Canonical(*delete as appropriate) FHS instead of a well-thought-out one.


Full ACK. ++
Therefore profile 17.1 has to be avoided and finally, if not avoidable, modified.

Regards, Gatsby
_________________
"Its your Gentoo, your way. When it breaks, you can keep all the pieces."
-- NeddySeagoon@forums.gentoo.org
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 9280

PostPosted: Tue Jul 23, 2019 6:25 pm    Post subject: Reply with quote

Profile 17.1 has nothing to do at all with split /usr, please don't spread falsehoods and rile up users into running unsupported profiles.

Last edited by asturm on Tue Jul 23, 2019 8:41 pm; edited 1 time in total
Back to top
View user's profile Send private message
Gatsby
Tux's lil' helper
Tux's lil' helper


Joined: 18 Jan 2010
Posts: 121
Location: 127.0.0.1

PostPosted: Tue Jul 23, 2019 6:31 pm    Post subject: Reply with quote

asturm wrote:
Profile 17.1 has nothing to do at all with this discussion, please don't spread falsehoods and rile up users into running unsupported profiles.

Profile 17.1 has a lot to do with this discussion and anyone is free to run what he wants.
_________________
"Its your Gentoo, your way. When it breaks, you can keep all the pieces."
-- NeddySeagoon@forums.gentoo.org
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 9280

PostPosted: Tue Jul 23, 2019 6:37 pm    Post subject: Reply with quote

Only as a result of your confirmation bias. Carefully pick your fights, Profile 17.1 is not it.

Gatsby wrote:
and anyone is free to run what he wants.

I'm also free to reject your bugs in this case.
Back to top
View user's profile Send private message
Gatsby
Tux's lil' helper
Tux's lil' helper


Joined: 18 Jan 2010
Posts: 121
Location: 127.0.0.1

PostPosted: Tue Jul 23, 2019 6:46 pm    Post subject: Reply with quote

asturm wrote:
Only as a result of your confirmation bias. Carefully pick your fights, Profile 17.1 is not it.

Profile 17.1 is what it is: a step in the wrong direction, like it or not.

asturm wrote:
I'm also free to reject your bugs in this case.

You are. You would not be addressed anyway.
_________________
"Its your Gentoo, your way. When it breaks, you can keep all the pieces."
-- NeddySeagoon@forums.gentoo.org
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 9280

PostPosted: Tue Jul 23, 2019 6:57 pm    Post subject: Reply with quote

Gatsby wrote:
asturm wrote:
I'm also free to reject your bugs in this case.

You are. You would not be addressed anyway.

Thanks in advance then.
Back to top
View user's profile Send private message
Gatsby
Tux's lil' helper
Tux's lil' helper


Joined: 18 Jan 2010
Posts: 121
Location: 127.0.0.1

PostPosted: Tue Jul 23, 2019 7:06 pm    Post subject: Reply with quote

asturm wrote:
Thanks in advance then.

Not at all.
_________________
"Its your Gentoo, your way. When it breaks, you can keep all the pieces."
-- NeddySeagoon@forums.gentoo.org
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6920

PostPosted: Tue Jul 23, 2019 7:18 pm    Post subject: Reply with quote

asturm wrote:
Profile 17.1 has nothing to do at all with this discussion, please don't spread falsehoods and rile up users into running unsupported profiles.

Profile 17.1 exists explicitly because of systemd being a problem child.
The change is designed to make Gentoo be more like unspecified “other Linux distributions”.
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 9280

PostPosted: Tue Jul 23, 2019 7:39 pm    Post subject: Reply with quote

If you don't look beyond the initial comment of that tracker bug, then sure, that's your opinion. If you think that distinct library arch install paths are a key component of independence to every Linux distribution, then that's your opinion, sure. I, for one, think that's a ridiculous viewpoint. And hypocritical, as loss of compatibility is always bemoaned when broken by systemd - rightfully so - but quickly discarded when it serves to dig in against a chosen enemy. Debian, if I'm not mistaken, are still using their crazy multiarch subdirs, but systemd is what you get when you install it. Profile 17.1 won't stop you from doing anything with Gentoo what you have been doing so far.

There are probably thousands of broken build systems out there that were only working on Gentoo (or not) by chance of having that /usr/lib symlink available. We fixed hundreds of them in the process and arguably made a big contribution to the communities that way.
Back to top
View user's profile Send private message
Tony0945
Watchman
Watchman


Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA

PostPosted: Wed Jul 24, 2019 12:40 am    Post subject: Reply with quote

virtual/tmpfiles
Code:
# Copyright 1999-2018 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2

EAPI=7

DESCRIPTION="Virtual to select between different tmpfiles.d handlers"
SLOT="0"
KEYWORDS="alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc x8>

RDEPEND="
    || (
        sys-apps/faketmpfiles
        sys-apps/opentmpfiles
    )"


sys-apps/faketmpfiles
Code:
# Copyright 1999-2018 Gentoo Authors
# Distributed under the terms of the GNU General Public License v3

EAPI=7

KEYWORDS="alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc x86 ~amd64-fbsd ~x86-fbsd"

DESCRIPTION="Fake utility to process systemd-style tmpfiles.d files, actually does nothing"
HOMEPAGE="nowhere"

LICENSE="GPL-3"
SLOT="0"
IUSE=""

RDEPEND=""

S="${WORKDIR}"

src_fetch() {
    cp "${FILESDIR}"/* "${S}"
}

src_compile()
{
     return
}

src_install() {
    default
}

sys-apps/faketmpfiles/files/tmpfiles
Code:
#!/bin/sh
# dummy executable

exit 0
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6148
Location: Dallas area

PostPosted: Wed Jul 24, 2019 12:44 am    Post subject: Reply with quote

I actually just added this
Code:
virtual/tmpfiles-0


to package.provided, and that shut it up,
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
saellaven
l33t
l33t


Joined: 23 Jul 2006
Posts: 654

PostPosted: Wed Jul 24, 2019 1:21 am    Post subject: Reply with quote

virtual/tmpfiles/tmpfiles-0.ebuild

Code:

# Copyright 1999-2018 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2

EAPI=6

DESCRIPTION="Virtual to select between different tmpfiles.d handlers"
SLOT="0"
KEYWORDS="alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc x86 ~x64-cygwin ~amd64-fbsd ~x86-fbsd ~amd64-linux ~x86-linux"

RDEPEND="
   || (
      sys-apps/openrc
      sys-apps/opentmpfiles
      sys-apps/systemd
   )"
Back to top
View user's profile Send private message
Tony0945
Watchman
Watchman


Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA

PostPosted: Wed Jul 24, 2019 1:32 am    Post subject: Reply with quote

saellaven wrote:
virtual/tmpfiles/tmpfiles-0.ebuild

Better than mine, except my overlay removes systemd as a choice from all ebuilds.

Just noticed my dummy executable doesn't have a name, so nothing executes it. So it isn't necessary.
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6148
Location: Dallas area

PostPosted: Wed Jul 24, 2019 10:26 pm    Post subject: Reply with quote

Well, if running an older openrc then you already have a "tmpfiles.sh" as part of it.

Code:
$ dir /bin/tmpfiles
lrwxrwxrwx 1 root root 22 Sep 30  2018 /bin/tmpfiles -> /lib/rc/sh/tmpfiles.sh
$ eq b /lib/rc/sh/tmpfiles.sh
 * Searching for /lib/rc/sh/tmpfiles.sh ...
sys-apps/openrc-0.13.11 (/lib64/rc/sh/tmpfiles.sh)


I just linked the tmpfiles.sh that's part of openrc to /bin/tmpfiles and set opentmpfiles as provided.
No need for a change to either virtual/tmpfiles or a dummy open/fake tmpfiles.
This way if there is a system.d type file that needs to be executed, it gets executed AND the emerge process is satisfied too.

This is from openrc tmpfiles.sh
Code:
# This is a reimplementation of the systemd tmpfiles.d code
# Control creation, deletion, and cleaning of volatile and temporary files


and this is from opentmpfiles/tmpfiles
Code:
# This is a reimplementation of the systemd tmpfiles.d code
# Control creation, deletion, and cleaning of volatile and temporary files


Lot of silliness to remove it from openrc and then add it back by way of a separate package :roll:
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6148
Location: Dallas area

PostPosted: Wed Jul 24, 2019 10:35 pm    Post subject: Reply with quote

asturm wrote:
Profile 17.1 has nothing to do at all with split /usr,


I'm sure that's the plan for 17.2 or maybe 18.0/19.0 :lol:
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 9280

PostPosted: Wed Jul 24, 2019 10:39 pm    Post subject: Reply with quote

Anon-E-moose wrote:
I'm sure that's the plan for 17.2 or maybe 18.0/19.0 :lol:

Since a new profile will be necessary for that, at this point it would definitely be 19.0, yes.
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6148
Location: Dallas area

PostPosted: Wed Jul 24, 2019 10:44 pm    Post subject: Reply with quote

I was just looking at the FHS 3.0 spec and what gentoo did with 17.0->17.1 seems to go against the standard, concerning lib being linked to either lib32 or lib64, when they exist, which they did/do under gentoo.

http://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 20485

PostPosted: Wed Jul 24, 2019 11:16 pm    Post subject: Reply with quote

Anon-E-moose wrote:
Lot of silliness to remove it from openrc and then add it back by way of a separate package :roll:
Is there some reason temporary files ought to be in an RC tool? Without knowing why it would be in there, it seems like it doesn't belong. In theory, it would seem to make more sense that a generic temporary file tool would be independent so that any init/RC tool didn't duplicate the general fucntion.


Anon-E-moose wrote:
I was just looking at the FHS 3.0 spec and what gentoo did with 17.0->17.1 seems to go against the standard, concerning lib being linked to either lib32 or lib64, when they exist, which they did/do under gentoo.

http://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html
A version of the baselayout ebuild tries to write to /usr/local (I still need to see about patching that). I think it's fair to say that "standards" are at best guidelines.

Gentoo does not consider the Filesystem Hierarchy Standard to be an authoritative standard, although much of our policy coincides with it.
_________________
Quis separabit? Quo animo?
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6148
Location: Dallas area

PostPosted: Wed Jul 24, 2019 11:31 pm    Post subject: Reply with quote

pjp wrote:
Anon-E-moose wrote:
Lot of silliness to remove it from openrc and then add it back by way of a separate package :roll:
Is there some reason temporary files ought to be in an RC tool? Without knowing why it would be in there, it seems like it doesn't belong. In theory, it would seem to make more sense that a generic temporary file tool would be independent so that any init/RC tool didn't duplicate the general fucntion.


But only openrc requires it/pulls it in. Which is why my original comment.

I agree that if other init systems used it, it would have made sense to factor it out of openrc.
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6148
Location: Dallas area

PostPosted: Wed Jul 24, 2019 11:36 pm    Post subject: Reply with quote

pjp wrote:
Anon-E-moose wrote:
I was just looking at the FHS 3.0 spec and what gentoo did with 17.0->17.1 seems to go against the standard, concerning lib being linked to either lib32 or lib64, when they exist, which they did/do under gentoo.

http://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html
A version of the baselayout ebuild tries to write to /usr/local (I still need to see about patching that). I think it's fair to say that "standards" are at best guidelines.

Gentoo does not consider the Filesystem Hierarchy Standard to be an authoritative standard, although much of our policy coincides with it.


And yet seemingly they consider RH (or as they say "other distros") to be an authoritative standard

As far as baselayout, I added this ">sys-apps/baselayout-2.4.1-r2" to package.mask a while back as I didn't want any further changes made to my filesystem.
If things need changing I'll do it by hand so that I know what's going on and why.
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 20485

PostPosted: Wed Jul 24, 2019 11:57 pm    Post subject: Reply with quote

Anon-E-moose wrote:
But only openrc requires it/pulls it in. Which is why my original comment.

I agree that if other init systems used it, it would have made sense to factor it out of openrc.
That's strange. How are temporary files handled without openrc or systemd? If other programs rely on that capability, it would seem odd for openrc (or similar) to be a dependency. And if systemd has resulted in other programs expecting it to be available, then the generic availability of temporary file management is necessary.

Anon-E-moose wrote:
And yet seemingly they consider RH (or as they say "other distros") to be an authoritative standard

As far as baselayout, I added this ">sys-apps/baselayout-2.4.1-r2" to package.mask a while back as I didn't want any further changes made to my filesystem.
If things need changing I'll do it by hand so that I know what's going on and why.
i'm only blocking >=2.6 and hoping nothing major happens. At some point, I'm anticipating it is going to become too difficult to try and work around. That's not why I have an OS, and that's mostly what I've been doing for a while.

As for the "authoritative RH standard," RH is the 800-lb gorilla. Maybe there's a conspiracy, but knowing what little I'm trying to manage around, I'd not want to be doing that as a developer. General issues are one thing, but how much of your free, volunteer time would you want to spend coding around systemd / RHisms?
_________________
Quis separabit? Quo animo?
Back to top
View user's profile Send private message
Tony0945
Watchman
Watchman


Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA

PostPosted: Thu Jul 25, 2019 12:19 am    Post subject: Reply with quote

Anon-E-moose wrote:
As far as baselayout, I added this ">sys-apps/baselayout-2.4.1-r2" to package.mask a while back as I didn't want any further changes made to my filesystem.
If things need changing I'll do it by hand so that I know what's going on and why.

Amen!
Code:
tony@MSI ~ $ grep baselayout /etc/portage/*.mask
sys-apps/baselayout::gentoo       # changes PATH + ?
tony@MSI ~ $ equery w baselayout
/var/lib/layman/oldgentoo/sys-apps/baselayout/baselayout-2.3.ebuild


tony@MSI ~ $ grep openrc /etc/portage/*.mask
sys-apps/openrc::gentoo  # stick with 0.17
tony@MSI ~ $ equery w openrc
/var/lib/layman/oldgentoo/sys-apps/openrc/openrc-0.17.ebuild
Back to top
View user's profile Send private message
389292
Guru
Guru


Joined: 26 Mar 2019
Posts: 504

PostPosted: Thu Jul 25, 2019 1:15 am    Post subject: Reply with quote

nowadays people are able to find controversy even in directory structure..
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Goto page 1, 2, 3  Next
Page 1 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum