| View previous topic :: View next topic |
| Author |
Message |
tld
Veteran
Joined: 09 Dec 2003
Posts: 1816
|
 Posted: Sun Dec 10, 2017 4:11 pm Post subject: |
 |
|
| Shamus397 wrote: | So at this point, SystemD has garnered most Linux distros as many are based upon Debian. As far as I can see, there was no 'Meeting of the Distro Minds' that happened here; it's a pretty straightforward case of hostile takeover on a one-by-one basis.
So am I mistaken about this? It seems to me such a internecine distro 'Meeting of the Linux Aristocracy' would have been big news, and widely reported; in all my study of the SystemD phenomenon I have never encountered any such record of such a meeting, not even a fleeting mention. Do any exist? |
Yea...those assertions are beyond revisionist. I'd say another factor was the unnecessary/malicious systemd dependency added to Gnome 3 and the fact that many distros used Gnome by defailt. I can't believe distros just rolled over and accepted that one.
As I mentioned above, my company is moving from CentOS 6 to Devuan for our products VM. They'd certainly contest that revisionist crap:
https://devuan.org/os/init-freedom/
From what I've seen so far, those folks have done an awesome job for sure. Interestingly...as I just added to the other thread here, as of their ascii release they're using eudev...cool.
Tom |
|
| Back to top |
|
 |
Fitzcarraldo
Advocate
Joined: 30 Aug 2008
Posts: 2034
Location: United Kingdom
|
| Posted: Sun Dec 10, 2017 9:01 pm Post subject: |
|
|
| Shamus397 wrote: | | Somewhere around this time, CentOS is embraced by Red Hat, and SystemD is subsequently found there |
Wasn't/isn't CentOS based on Red Hat anyway? So presumably, once Red Hat adopted systemd in Red Hat 7, CentOS would have automatically included systemd.
In the early days, all the proponents of systemd really touted its supposed faster boot times. For example, the author of the December 2011 article Here We Go Again, Another Linux Init: Intro to systemd mentioned ‘Faster Startups’ early on, whereas in a September 2014 article Understanding and Using Systemd, the same author states:
| Carla Schroder wrote: | | For whatever reason, it seems that the proponents of SysVInit replacements are obsessed with boot times. My systemd systems, like CentOS 7, don’t boot up all that much faster than the others. It’s not something I particularly care about in any case, since most boot speed measurements only measure reaching the login prompt, and not how long it takes for the system to completely start and be usable. |
Many people do not reboot frequently (I tend to suspend my laptop rather than power it down, unless I am travelling). On my non-systemd laptops (Core i7), the start-up of KDE Plasma 5 takes a lot longer than the OS itself takes to boot. And on another laptop and virtual machines I've noticed that systemd can take longer to shutdown than machines not using systemd. I think these are the reasons the 'faster booting' assertion is no longer mentioned.
_________________
Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC udev elogind & KDE on both.
Fitzcarraldo's blog |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Sun Dec 10, 2017 9:47 pm Post subject: |
|
|
| Fitzcarraldo wrote: | | Shamus397 wrote: | | Somewhere around this time, CentOS is embraced by Red Hat, and SystemD is subsequently found there |
Wasn't/isn't CentOS based on Red Hat anyway? So presumably, once Red Hat adopted systemd in Red Hat 7, CentOS would have automatically included systemd.
In the early days, all the proponents of systemd really touted its supposed faster boot times. For example, the author of the December 2011 article Here We Go Again, Another Linux Init: Intro to systemd mentioned ‘Faster Startups’ early on, whereas in a September 2014 article Understanding and Using Systemd, the same author states:
| Carla Schroder wrote: | | For whatever reason, it seems that the proponents of SysVInit replacements are obsessed with boot times. My systemd systems, like CentOS 7, don’t boot up all that much faster than the others. It’s not something I particularly care about in any case, since most boot speed measurements only measure reaching the login prompt, and not how long it takes for the system to completely start and be usable. |
Many people do not reboot frequently (I tend to suspend my laptop rather than power it down, unless I am travelling). On my non-systemd laptops (Core i7), the start-up of KDE Plasma 5 takes a lot longer than the OS itself takes to boot. And on another laptop and virtual machines I've noticed that systemd can take longer to shutdown than machines not using systemd. I think these are the reasons the 'faster booting' assertion is no longer mentioned. |
it's called "moving the goalposts" and its a constant problem with Systemd proponents and developers. They come out with some grand statement, people then spend time and effort refuting it BUT then then they change the talking point pushing that isn't relative in the (new) grand scheme of thing's. You then get labelled as a troll and your statements dismissed on the basis you are a troll... meanwhile the tripe continues to fester...
The more I am seeing how FOSS projects run, projects that get themselves into "key" positions, COUPLED with Microsoft and windows10... the more I come to the conclusion the software industry is not fit for self-governance.
There is the Common Vulnerabilities and Exposures (CVE) but it isn't good enough because the industry has shown it isn't good enough.
I am an avionics engineer and I believe it is time FOSS (and MS) either voluntarily accept comparable processes or are made to via regulation & I take this stance because software is now everywhere and the flaws impact health and safety.
If a feature is conceived (either internally or via some focus group/requests etc) then it is fully documented, requirements are written, requirements a reviewed, requirements are acted upon.
DO178 calls for certain processes with regards to flow-down of request. You cannot just add something in code without some requirement & that requirement either needs valid rational for derived or is a clear flow-down to a validated parent. The code is commented, the code is audit-able, the code is under change control. At multiple stages SOI audit's are held and minuted to show adherence to the process and gaps in the process. Finally the full test coverage against the agreed specification must be submitted in a form of DDP and any deviations from this have an associated problem report raised and every single problem report is classified as per CRI-F32 equivalent (0: safety impact, 1: failure, 2: fault, 3: process deviation) and the graded (A,B). The gradings are agreed by those involved at the SOI.
Simply put software engineers can no longer be trusted to write software
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
Fitzcarraldo
Advocate
Joined: 30 Aug 2008
Posts: 2034
Location: United Kingdom
|
| Posted: Mon Dec 11, 2017 2:38 am Post subject: |
|
|
| tld wrote: | As I mentioned above, my company is moving from CentOS 6 to Devuan for our products VM. They'd certainly contest that revisionist crap:
https://devuan.org/os/init-freedom/ |
Hadn't seen that FSCONS 2016 video before; it's an interesting presentation. A couple of things he mentioned stuck out: a) they are planning to release HEADS, a non-systemd alternative to Tails (18:44); b) he likes OpenRC (36:58), which 'is completely broke[n]' in Debian.
_________________
Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC udev elogind & KDE on both.
Fitzcarraldo's blog |
|
| Back to top |
|
|
Fitzcarraldo
Advocate
Joined: 30 Aug 2008
Posts: 2034
Location: United Kingdom
|
| Posted: Mon Dec 11, 2017 2:59 am Post subject: |
|
|
| Shamus397 wrote: | It could well be that my interlocutor was of the mistaken impression that he was informed on the subject, when he clearly wasn't. The account given by Lord Chesterfield of his attempts to reform the calender in England is likely instructive, as the tactics he used on the House of Lords is eerily similar to the methods employed by the SystemD cabal:
| Lord Chesterfield, in 1751 wrote: | | It was notorious, that the Julian Calendar was erroneous, and had overcharged the solar year with eleven days. Pope Gregory the Thirteenth corrected this error [in 1582]; his reformed calendar was immediately received by all the Catholic powers of Europe, and afterwards adopted by all the Protestant ones, except Russia, Sweden, and England. It was not, in my opinion, very honourable for England to remain in a gross and avowed error, especially in such company; the inconveniency of it was likewise felt by all those who had foreign correspondences, whether political or mercantile. I determined, therefore, to attempt the reformation; I consulted the best lawyers, and the most skillful astronomers, and we cooked up a bill for that purpose. But then my difficulty began; I was to bring in this bill, which was necessarily composed of law jargon and astronomical calculations, to both of which I am an utter stranger. However, it was absolutely necessary to make the House of Lords think that I knew something of the matter; and also to make them believe that they knew something of it themselves, which they do not. For my own part, I could just as soon have talked Celtic or Sclavonian to them, as astronomy, and they would have understood me full as well; so I resolved to do better than speak to the purpose, and to please instead of informing them. I gave them, therefore, only an historical account of calendars, from the Egyptian down to the Gregorian, amusing them now and then with little episodes; but I was particularly attentive to the choice of my words, to the harmony and roundness of my periods, to my elocution, to my action. This succeeded, and ever will succeed; they thought I informed them, because I pleased them; and many of them said I had made the whole very clear to them; when, God knows, I had not even attempted it. |
|
I take your point, but that is probably not the best example to choose, as the Gregorian calendar is an improvement on the Julian calendar! With the Julian calendar, the seasons gradually lag behind the calendar date as the centuries progress. For example, today, December 11, 2017, would be 28 November, 2017 in the Julian calendar.
_________________
Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC udev elogind & KDE on both.
Fitzcarraldo's blog |
|
| Back to top |
|
|
Shamus397
Apprentice
Joined: 03 Apr 2005
Posts: 218
Location: Ur-th
|
| Posted: Mon Dec 11, 2017 3:25 am Post subject: |
|
|
The point of the Lord Chesterfield quote was not to show that it was a bad thing that Britain moved on to the Gregorian Calendar, but to show that politically motivated manipulation is very old, and that those who are on the receiving end of being informed by experts are usually being sold a bill of goods in which they think they are being informed when, in fact, they are being manipulated to believe that they are informed and thus capable of making rational judgements.
In this case it was a noble goal being achieved by slimy means; my intention was to hold up those slimy means as instructive to the considerably less-than-noble goals being pushed and the methods employed to achieve said goals by the SystemD cabal. My apologies if that wasn't clear.  |
|
| Back to top |
|
|
Shamus397
Apprentice
Joined: 03 Apr 2005
Posts: 218
Location: Ur-th
|
| Posted: Mon Dec 11, 2017 3:28 am Post subject: |
|
|
| Fitzcarraldo wrote: | | Shamus397 wrote: | | Somewhere around this time, CentOS is embraced by Red Hat, and SystemD is subsequently found there |
Wasn't/isn't CentOS based on Red Hat anyway? So presumably, once Red Hat adopted systemd in Red Hat 7, CentOS would have automatically included systemd. |
Yes, CentOS was and is based on Red Hat, but the move by Red Hat to embrace the CentOS developers was unprecedented, and timewise, coincided with the big SystemD push. Coincidence? I have a hard time believing that. |
|
| Back to top |
|
|
Fitzcarraldo
Advocate
Joined: 30 Aug 2008
Posts: 2034
Location: United Kingdom
|
| Posted: Mon Dec 11, 2017 3:28 am Post subject: |
|
|
| Shamus397 wrote: | The point of the Lord Chesterfield quote was not to show that it was a bad thing that Britain moved on to the Gregorian Calendar, but to show that politically motivated manipulation is very old, and that those who are on the receiving end of being informed by experts are usually being sold a bill of goods in which they think they are being informed when, in fact, they are being manipulated to believe that they are informed and thus capable of making rational judgements.
In this case it was a noble goal being achieved by slimy means; my intention was to hold up those slimy means as instructive to the considerably less-than-noble goals being pushed and the methods employed to achieve said goals by the SystemD cabal. My apologies if that wasn't clear. |
Yes, it was crystal clear (hence my "I take your point"). I just think it would be better to use an example which mirrors the systemd situation, i.e. the result is arguably worse, not better.
_________________
Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC udev elogind & KDE on both.
Fitzcarraldo's blog |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Mon Dec 11, 2017 2:23 pm Post subject: |
|
|
| Fitzcarraldo wrote: | | Yes, it was crystal clear (hence my "I take your point"). I just think it would be better to use an example which mirrors the systemd situation, i.e. the result is arguably worse, not better. |
How about the Iraq war and "We know Iraq has weapons of mass destruction, but the details are classified, just trust us"? |
|
| Back to top |
|
|
miket
Guru
Joined: 28 Apr 2007
Posts: 488
Location: Gainesville, FL, USA
|
| Posted: Mon Dec 11, 2017 5:43 pm Post subject: |
|
|
| Fitzcarraldo wrote: | | they are planning to release HEADS, a non-systemd alternative to Tails |
Funny, I had just been thinking that the mark of Devuan's making it into the big time would be the appearance of the first Devuan derivative. I guess now there will be one.
The reason I was thinking about Devuan was this Slashdot article: https://linux.slashdot.org/story/17/12/11/0049245/does-systemd-makes-linux-complex-error-prone-and-unstable
It turns out that a VM provider has given up on fixing problems of systemd's making and has switched to Devuan. |
|
| Back to top |
|
|
roki942
Apprentice
Joined: 18 Apr 2005
Posts: 285
Location: Seattle
|
| Posted: Mon Dec 11, 2017 8:07 pm Post subject: |
|
|
| https://devuan.org/Which includes the testing release of Heads. |
|
| Back to top |
|
|
saellaven
l33t
Joined: 23 Jul 2006
Posts: 646
|
| Posted: Wed Jan 03, 2018 10:31 pm Post subject: |
|
|
As of portage-2.3.19-r1, portage is now infected with mandatory tmpfiles, because
| Quote: | | By default, systemd-tmpfiles removes files older than 30 days from /var/tmp. The default portage config sets CCACHE_DIR=/var/tmp/ccache. |
Given that I'm still on openrc-0.17 since I don't want williamh's systemd infected newer versions of openrc, I've gone back to the stable version of portage until I have the time to deal with it. |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Wed Jan 03, 2018 10:44 pm Post subject: |
|
|
This is only an issue if you use systemd + portage which since you use openRC you are not affected by systemd autoclearing var tmp
I agree it isn't good others are having to work around further bullshit of systemd
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Wed Jan 03, 2018 11:43 pm Post subject: |
|
|
| saellaven wrote: | | Given that I'm still on openrc-0.17 since I don't want williamh's systemd infected newer versions of openrc, I've gone back to the stable version of portage until I have the time to deal with it. |
Me too. Glad I'm not alone. |
|
| Back to top |
|
|
saellaven
l33t
Joined: 23 Jul 2006
Posts: 646
|
| Posted: Thu Jan 04, 2018 12:00 am Post subject: |
|
|
| Naib wrote: | This is only an issue if you use systemd + portage which since you use openRC you are not affected by systemd autoclearing var tmp
I agree it isn't good others are having to work around further bullshit of systemd |
portage now inherits tmpfiles, causing a block for those of us on older versions of openrc
| Code: |
[ebuild U ~] sys-apps/portage-2.3.19-r1::gentoo [2.3.19::gentoo]
USE="(ipc) native-extensions xattr -build -doc -epydoc (-selinux)"
LINGUAS="-ru" PYTHON_TARGETS="python2_7 python3_5 -pypy -python3_4
-python3_6" 0 KiB
[blocks B ] <sys-apps/openrc-0.23 ("<sys-apps/openrc-0.23" is blocking
sys-apps/opentmpfiles-0.1.3)
Total: 11 packages (9 upgrades, 2 new), Size of downloads: 6680 KiB
Conflict: 1 block (1 unsatisfied)
* Error: The above package list contains packages which cannot be
* installed at the same time on the same system.
(sys-apps/openrc-0.17:0/0::keri-overlay, installed) pulled in by
sys-apps/openrc required by (virtual/service-manager-0:0/0::gentoo,
installed)
>=sys-apps/openrc-0.15 required by (net-misc/netifrc-0.5.1:0/0::gentoo,
installed)
(sys-apps/opentmpfiles-0.1.3:0/0::gentoo, ebuild scheduled for merge)
pulled in by
sys-apps/opentmpfiles required by (virtual/tmpfiles-0:0/0::gentoo,
ebuild scheduled for merge)
|
So yeah, while it's a systemd caused bug, it IS affecting non-systemd users since williamh keeps crippling openrc with systemd's "features" |
|
| Back to top |
|
|
tld
Veteran
Joined: 09 Dec 2003
Posts: 1816
|
| Posted: Thu Jan 04, 2018 12:22 am Post subject: |
|
|
| I've always used the stable portage, so I haven't run into this, but clearly I will eventually. When's this bullshit going to end? Can't openrc be rescued from these the systemd shills somehow? This is unacceptable. |
|
| Back to top |
|
|
proteusx
Guru
Joined: 21 Jan 2008
Posts: 338
|
| Posted: Thu Jan 04, 2018 12:32 am Post subject: |
|
|
I did this and it seems to remove the block without any adverse effects (so far).
| Code: | | echo "sys-apps/opentmpfiles-0.1.3" >> /etc/portage/profile/package.provided |
|
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Thu Jan 04, 2018 1:30 am Post subject: |
|
|
| proteusx wrote: | I did this and it seems to remove the block without any adverse effects (so far).
| Code: | | echo "sys-apps/opentmpfiles-0.1.3" >> /etc/portage/profile/package.provided |
|
IOW the dependency is bullshit. |
|
| Back to top |
|
|
berferd
Tux's lil' helper
Joined: 13 May 2004
Posts: 117
|
| Posted: Thu Jan 04, 2018 1:43 am Post subject: |
|
|
| The workarounds are piling up. |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Thu Jan 04, 2018 1:53 am Post subject: |
|
|
I would really feel better if someone would fork OpenRC. I'm sticking with the main branch, evil systemd changes and all, because I really dislike running "dead" software. If someone forked it, I'd switch in a minute, just because it was "alive".
The tmpfiles thing doesn't particularly bother me, because I haven't run into it. I don't run ccache, and if I did I'd set CCACHE_DIR myself. I also have a bunch of memory (32G) and implement /tmp and /var/tmp as tdisk anyway. I rather like having those directories aggressively skulked.
On one system I'm having far bigger problems with modules - starting a year ago, when that crap was changed. That system has spent most of a year dead, because I've had bigger fish to fry. Right now I can't force modules to autoload at all, either old way or new way. Some do it on their own, but stuff in the architected files of either vintage don't work. In particular I'm having trouble with mceusb and snd-hda-intel. Curious thing is that rc.log tells me that both have loaded, but lsmod says that they're not.
I really haven't taken the time to bug this out - still. Maybe one of these days.
One suggestion - for portage... Isn't there a way to introduce patches into packages? Any reason we couldn't patch portage that way, if only for things liek CCACHE_DIR? With that and a fork of OpenRC, life might be grand. (again)
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21635
|
| Posted: Thu Jan 04, 2018 3:30 am Post subject: |
|
|
| Tony0945 wrote: | | proteusx wrote: | I did this and it seems to remove the block without any adverse effects (so far).
| Code: | | echo "sys-apps/opentmpfiles-0.1.3" >> /etc/portage/profile/package.provided |
|
IOW the dependency is bullshit. |
Not necessarily. I recently saw a post in another thread that asserted old openrc bundled opentmpfiles type functionality in the main package. Later openrc split it out. There are several possibilities here:- proteusx did break something, but the adverse effect has not yet been observed (or if observed, not traced to the package.provided change)
- The dependency is real, but the opentmpfiles bundled in old openrc is sufficient to satisfy whatever requirement Portage has, meaning that the package.provided change is effectively correct, since old openrc does provide (at least some of) opentmpfiles.
- The dependency is bogus.
I have no time to determine which of these is the case. |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Thu Jan 04, 2018 9:00 am Post subject: |
|
|
| Tony0945 wrote: | | IOW the dependency is bullshit. |
| Hu wrote: | | Not necessarily. I recently saw a post in another thread that asserted old openrc bundled opentmpfiles type functionality in the main package. Later openrc split it out. |
Hu ... here, and it's a fact :). I forget when it was added, but it wasn't long after systemd implimented it. Going by the changelog the split happened April 2017 (so, after the version ... 0.17 ... Tony0945, proteusx, et al, are using).
| Hu wrote: | There are several possibilities here:- proteusx did break something, but the adverse effect has not yet been observed (or if observed, not traced to the package.provided change)
- The dependency is real, but the opentmpfiles bundled in old openrc is sufficient to satisfy whatever requirement Portage has, meaning that the package.provided change is effectively correct, since old openrc does provide (at least some of) opentmpfiles.
- The dependency is bogus.
I have no time to determine which of these is the case. |
The second, but all this is moot, the dependency is there as all versions < 0.28 (so those prior to the split) are nolonger in tree:
| eshowkw sys-apps/openrc: | # Keywords for sys-apps/openrc:
| | u |
| a a p a n r s | n |
| l m h i p r m m i i s p | e u s | r
| p d a p a p c x m i 6 o s 3 a | a s l | e
| h 6 r p 6 p 6 8 6 p 8 s c 9 s r | p e o | p
| a 4 m a 4 c 4 6 4 s k 2 v 0 h c | i d t | o
--------+---------------------------------+-------+-------
0.28 | + + + + + + + + ~ ~ ~ o o ~ ~ + | 6 # 0 | gentoo
0.32.1 | + + ~ + + + + + ~ ~ ~ o o ~ ~ + | 6 # | gentoo
0.34.11 | + + + + + + + + + ~ ~ o o ~ ~ + | 6 o | gentoo
9999 | o o o o o o o o o o o o o o o o | 6 o | gentoo |
| equery -NC depgraph =sys-apps/openrc-0.28 | grep tmpfiles: | | `-- virtual/tmpfiles-0 (virtual/tmpfiles) x86 |
... none the less, any version >=sys-apps/openrc-0.12.4 (and perhaps earlier) will have the 'opentempfiles' implimentation, and may even be runing it (as tmpfiles.{dev,setup} are added to the runlevel when installing):
| Code: | | # rc-status --all | grep tmpfiles |
best ... khay |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Thu Jan 04, 2018 2:51 pm Post subject: |
|
|
@khyayam As always, you are correct | Code: | gentoo ~ # rc-status --all | grep tmpfiles
tmpfiles.setup [ started ]
tmpfiles.dev [ started ]
gentoo ~ # equery w openrc
/usr/local/oldgentoo/sys-apps/openrc/openrc-0.17.ebuild
|
| depontius wrote: | | One suggestion - for portage... Isn't there a way to introduce patches into packages? Any reason we couldn't patch portage that way, if only for things liek CCACHE_DIR? With that and a fork of OpenRC, life might be grand. (again) |
IMHO, even IF there was a reason for these changes, they should have been implemented as optional features controlled by useflags. As it is, those of us who don't want them are denied any bug fixes that may have came along with them. Yes, a patched version with useflags could be made and put into public overlay. In my opinion, it would be a target for malicious programming to destroy it by deliberately forcing incompatibilities in the main tree. Because the goal isn't improving openrc. The goal is destroying openrc, runit, s6 and any alternative save systemd. |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Thu Jan 04, 2018 3:47 pm Post subject: |
|
|
| Code: | mkdir /usr/local/portage/sys-apps/portage/files -p
cp portage-2.3.19-r2.ebuild /usr/local/portage/sys-apps/portage
touch /usr/local/portage/sys-apps/portage/files/portage-ccache.conf
ebuild /usr/local/portage/sys-apps/portage/portage-2.3.19-r2.ebuild digest
emerge -1 portage
|
| Code: | ls /usr/lib/tmpfiles.d/
lvm2.conf man-db.conf minidlna.conf portage-ccache.conf revdep-rebuild.conf
|
This to prove portage doesn't need anything from tmpfiles.d to work and install the file as need, and the only change i've done was removing the stupid inherit and change the dotmpfiles with "normal" portage doins function.
I have open bug for that: https://bugs.gentoo.org/643386
And you can see the changes (nothing fancy) made to have : portage installing and fixing systemd bug, while portage doesn't depend on tmpfiles or any init.
| Code: | -- portage-2.3.19-r1.ebuild 2018-01-04 16:48:28.073036386 +0100
+++ portage-2.3.19-r2.ebuild 2018-01-04 16:47:23.793839987 +0100
@@ -10,7 +10,7 @@
)
PYTHON_REQ_USE='bzip2(+),threads(+)'
-inherit distutils-r1 tmpfiles
+inherit distutils-r1
DESCRIPTION="Portage is the package management and distribution system for Gentoo"
HOMEPAGE="https://wiki.gentoo.org/wiki/Project:Portage"
@@ -203,7 +203,8 @@
esetup.py "${targets[@]}"
fi
- dotmpfiles "${FILESDIR}"/portage-ccache.conf
+ insinto /usr/lib/tmpfiles.d
+ doins "${FILESDIR}"/portage-ccache.conf
# Due to distutils/python-exec limitations
# these must be installed to /usr/bin.
|
|
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Thu Jan 04, 2018 3:54 pm Post subject: |
|
|
| krinn wrote: | | Code: | mkdir /usr/local/portage/sys-apps/portage/files -p
cp portage-2.3.19-r2.ebuild /usr/local/portage/sys-apps/portage
touch /usr/local/portage/sys-apps/portage/files/portage-ccache.conf
ebuild /usr/local/portage/sys-apps/portage/portage-2.3.19-r2.ebuild digest
emerge -1 portage
|
| Code: | ls /usr/lib/tmpfiles.d/
lvm2.conf man-db.conf minidlna.conf portage-ccache.conf revdep-rebuild.conf
|
This to prove portage doesn't need anything from tmpfiles.d to work and install the file as need, and the only change i've done was removing the stupid inherit and change the dotmpfiles with "normal" portage doins function.
I have open bug for that: https://bugs.gentoo.org/643386
And you can see the changes (nothing fancy) made to have : portage installing and fixing systemd bug, while portage doesn't depend on tmpfiles or any init.
| Code: | -- portage-2.3.19-r1.ebuild 2018-01-04 16:48:28.073036386 +0100
+++ portage-2.3.19-r2.ebuild 2018-01-04 16:47:23.793839987 +0100
@@ -10,7 +10,7 @@
)
PYTHON_REQ_USE='bzip2(+),threads(+)'
-inherit distutils-r1 tmpfiles
+inherit distutils-r1
DESCRIPTION="Portage is the package management and distribution system for Gentoo"
HOMEPAGE="https://wiki.gentoo.org/wiki/Project:Portage"
@@ -203,7 +203,8 @@
esetup.py "${targets[@]}"
fi
- dotmpfiles "${FILESDIR}"/portage-ccache.conf
+ insinto /usr/lib/tmpfiles.d
+ doins "${FILESDIR}"/portage-ccache.conf
# Due to distutils/python-exec limitations
# these must be installed to /usr/bin.
|
|
This is the key part of the bugreport
| Quote: | | portage shouldn't depend on any init system as long as portage has no need for anything for an init system. |
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
|
|
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
|
|
Gentoo Chat
