| View previous topic :: View next topic |
| Author |
Message |
arnvidr
l33t
Joined: 19 Aug 2004
Posts: 629
Location: Oslo, Norway
|
 Posted: Thu Dec 03, 2015 7:45 am Post subject: Shall we free-rc? |
 |
|
Split off the OpenRC fork discussion from The Politics of systemd Part 2 at about this point. — JRG
Which reminds me, does anyone maintain a sort-of fork of openrc? The last release, which I (to be fair) haven't been hindered by yet, completely broke mounting in my opinion (which we discussed for a bit). I haven't reverted that (yet), but if someone is maintaining a patched version or something I'd be happy to be a guinea pig (especially since I don't have any esoteric boot needs  )
_________________
|
|
| Back to top |
|
 |
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Thu Dec 03, 2015 8:17 am Post subject: |
|
|
| arnvidr wrote: | | Which reminds me, does anyone maintain a sort-of fork of openrc? The last release, which I (to be fair) haven't been hindered by yet, completely broke mounting in my opinion (which we discussed for a bit). I haven't reverted that (yet), but if someone is maintaining a patched version or something I'd be happy to be a guinea pig (especially since I don't have any esoteric boot needs :P ) |
arnvidr ... if I add x,y,z to version 1.2.3, making it 1.2.4, and you then remove x,y,z ... it's now 1.2.3 again ;). So really, the question is: is there any reason to make it worth updating, are any of the applied "fixes" such that its worth forking so as to gain these, but loose the brokages? I was watching openrc commits for a while (after the 'runscript' => 'openrc-run' nonsense) and it hardly seemed worth doing so, in fact, the best thing it seemed to me was to mask >=sys-apps/openrc-0.13.7 and be done with it.
best ... khay |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Thu Dec 03, 2015 10:38 am Post subject: |
|
|
| khayyam wrote: | | ..if I add x,y,z to version 1.2.3, making it 1.2.4, and you then remove x,y,z ... it's now 1.2.3 again ;). So really, the question is: is there any reason to make it worth updating, are any of the applied "fixes" such that its worth forking so as to gain these, but loose the brokages? I was watching openrc commits for a while (after the 'runscript' => 'openrc-run' nonsense) and it hardly seemed worth doing so, in fact, the best thing it seemed to me was to mask >=sys-apps/openrc-0.13.7 and be done with it. |
Ah good one; now we have a known-point to work toward (not from, yet) and a default mask for usage in the meanwhile.
Thanks for doing the legwork (I couldn't face reviewing any more of the git history; it goes downhill so much after Marples left, that it's quite depressing.) |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Thu Dec 03, 2015 1:23 pm Post subject: |
|
|
| steveL wrote: | | Ah good one; now we have a known-point to work toward (not from, yet) and a default mask for usage in the meanwhile. |
steve ... perhaps I should have mentioned that the above mask will require =sys-apps/openrc-0.12.4 (no longer in tree) and that the following packages will need masking so that you're not plagued by "<sys-apps/openrc-0.13 is blocking". This will be the case for sys-fs/udev-init-scripts-27 and no doubt {e,}udev (neither of which, as you know, I have installed).
| /etc/portage/package.mask: | >=sys-apps/openrc-0.13.7
>=sys-apps/kmod-19
>=net-fs/nfs-utils-1.3.1-r1 |
| steveL wrote: | | Thanks for doing the legwork (I couldn't face reviewing any more of the git history; it goes downhill so much after Marples left, that it's quite depressing.) |
I agree ... you could group the changes to openrc into two classes, silly changes like 'runscript > openrc-run', and "how do we follow upstream 'requirements' like good little puppies". There is probably a third class consisting of "actual problems" but these are barely noticeable due to the predominance of the other two. A fork should be quite simple to manage as you can basically ignore everything subsequent to whatever version you decide to take as your base ... one exception would be 'runscript => openrc-run' (so, 0.13.11) you won't be able to ignore that as "eventually" (haha!) init scripts will be migrated to openrc-run, users will stop having to retro-fix their hash-bangs on "routine updates", and the debian developers, who ask for the change, will be able to sleep soundly in their beds.
HTH & best ... khay |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Thu Dec 03, 2015 3:48 pm Post subject: |
|
|
| khayyam wrote: | .. the above mask will require =sys-apps/openrc-0.12.4 (no longer in tree) and that the following packages will need masking so that you're not plagued by "<sys-apps/openrc-0.13 is blocking". This will be the case for sys-fs/udev-init-scripts-27 and no doubt {e,}udev (neither of which, as you know, I have installed).
| /etc/portage/package.mask: | >=sys-apps/openrc-0.13.7
>=sys-apps/kmod-19
>=net-fs/nfs-utils-1.3.1-r1 |
|
Lovely, thanks :-)
Yeah definitely time to switch to eudev, with vdev up as a long-term alternative going forward. (Nice work on libudev-compat, for example.)
Hmm kmod and nfs-utils may need patching, after review for lunacy. Don't suppose you've got bug ids? A summary from you as to issue would still be much appreciated, either way.
| Quote: | | A fork should be quite simple to manage as you can basically ignore everything subsequent to whatever version you decide to take as your base ... one exception would be 'runscript => openrc-run' (so, 0.13.11) you won't be able to ignore that as "eventually" (haha!) init scripts will be migrated to openrc-run, users will stop having to retro-fix their hash-bangs on "routine updates", and the debian developers, who ask for the change, will be able to sleep soundly in their beds. |
Heh, well the base version is likely to be quite far back, and involve changes to underlying shell-scripts (to stop them causing professional scripters to want to tear their eyes out..;) then roll-forward reviewing the third class of changes you mentioned.
Sometimes things have been done, then backed out later, so checking current at the same time is necessary. Essentially a synthesis, so I guess we could clean up what's there, but it's actually easier for me at least to do it like that, if more time-consuming. It means you get a much better understanding of everything that's gone on, as well as a cleaner history free of nutjob stabs-in-the-dark, usually untested before infliction on end-users. ("but look: we did all the bug-tracking!")
The shebang is not going to be an issue; if someone wants to use it on debian, and debilian are still being dumbass about minicom vs openrc, then we'll simply rewrite the shebang on install, which is something we already do in our makefiles, to support things like gentoo-prefix cleanly. In passing, I note that since every runscript is run via a shebang, the question of @sbindir@/runscript being a problem, really feels like a non-issue. (Aren't people using minicom's *'/bin/runscript' using it via a similar mechanism?)
It may require patching some packages in an overlay; hardly onerous, and we'll look to automate patching it, so we don't need to change ebuild sources at all, if possible.
It should be even less of a problem given that m1-style @ substitutions (autoconf subst vars) are in-play, which is why I never understood the approach of breaking everyone else's system just to cope with one distro, which wasn't even distributing it at the time.
The only feasible justification is if you want to write openrc runscripts once, and run everywhere, which is simply pathetic reaching, since as we've already seen, you potentially have to rewrite the shebang on install in any case, as we already do, so no-one can distribute a runscript that will work everywhere out of the box.
Only the base that works for the default, which must be checked for validity at package-install, in any case (or YDIW.)
An end-user is going to be using one distro, perhaps under a custom prefix, and comfortable with however that operates; via the simple expediency of copying a minimal runscript.
IOW it's papering over bugs in a hypothetical scenario that no user really needs to care about.
= the politics of this =
It's odd how Hubbs thinks, say busybox needs to be patched to fix its "bugs" before we can cope with it, even though it's perfectly simple to work with it out-of-the-box, and has taken similar stances for other projects like the kernel, of all things; but at other times, he's all for "convenience" in a functionally-useless approach, used as justification for nonsensical changes.
Still, no point pondering on the thought-process, when the end-result is so clearly borked, any more than we want to understand what Poeterring is ranting about this week.
Sometimes you just have to flip the bozo-bit; if it's not someone you actually care about on a personal level, why bother waiting however many years it may take for them to see the point; or "grow on a personal level", if you want a fuzzy variant. ;)
Someone may well have a point, or a use-case in mind. That doesn't mean they are any good at communicating it, which is required for design, nor at implementing it.
And the social negatives can outweigh any (usually unfounded, ime) technical "merit": cf: Ciaran McCreesh for the textbook example (definitely unfounded, afaic: pedantry, especially when combined with a fetish for the baroque, does not a result make.)
Wrt runscript change: if I had to guess, someone's drunk the "container requires systemdbust" kool-aid, because "containers are new, innovative" and not at all simply a reflection of how poorly Linux stacks up against the BSDs.
(TF it's finally catching up: but still nowhere near as clean as BSD jails, and I don't trust this bunch of self-styled "userland experts" to deliver anything even half as good, and what they do deliver is likely only to be configurable via a god-foresaken dbust-interface no-one in their right mind wants to use, nor code against. Why reinvent the text file, so badly?)
In this world-view, everything must be at a fixed location, across the whole Unixverse, or lamer-wannabes will be unable to cope. (You must want them sorting out initscripts, right?)
Since we're talking about shebangs, none of this makes any sense to my build-system work mind.
Containers are simply the pretext, and no I cannot follow the logic either; anyone would think they'd never heard of a "distribution" before, let alone heterogeneous computing.
Choosing a distro which cannot even provide etc-update, as your basis, so now you're throwing a tantrum if fixed locations aren't provided scattered across the hierarchy; but all binaries must go in the one directory..
Words fail, and only laughter suffices. |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Thu Dec 03, 2015 4:26 pm Post subject: |
|
|
| khayyam wrote: | .. the above mask will require =sys-apps/openrc-0.12.4 (no longer in tree) and that the following packages will need masking so that you're not plagued by "<sys-apps/openrc-0.13 is blocking". This will be the case for sys-fs/udev-init-scripts-27 and no doubt {e,}udev (neither of which, as you know, I have installed).
| /etc/portage/package.mask: | >=sys-apps/openrc-0.13.7
>=sys-apps/kmod-19
>=net-fs/nfs-utils-1.3.1-r1 |
|
| steveL wrote: | | Hmm kmod and nfs-utils may need patching, after review for lunacy. Don't suppose you've got bug ids? A summary from you as to issue would still be much appreciated, either way. |
steve ... I don't think they require patching, the issue with nfs-utils is specific wrt changes to 'netmount' (the entire 'discussion' leading up to the recent '2015-10-07 openrc 0.18 localmount and netmount changes' news item). Here's the bug, the upshot of which is dependencies (ie, whether netmount can depend on net-fs/nfs-utils being installed ... or not), and so the roles of netmount, nfsclient, etc, what is doing what, to whom, and in what lavatory.
As far as kmod is concerned, other than the mask being simply my avoidance of "<sys-apps/openrc-0.13 is blocking" I'm rather more vague ... I'm fairly sure it relates to init.d/modules itself (rather than kmod), but I can't find anything in the Changelog other than "adjust the openrc blocker to !<0.13.8" ... and I'm not having any luck finding a bug that provides the reasoning behind it.
best ... khay |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Thu Dec 03, 2015 4:35 pm Post subject: |
|
|
funtoo carries their own patchset
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Thu Dec 03, 2015 5:54 pm Post subject: |
|
|
Most of the ">=", ">", "<" <pkgname-pkgversion> in ebuilds are relatively new inventions (last year or so).
In many cases, in the past, I've been able to modify the ebuild
ie. change ">=cups-1.9.5" to just "cups" and the programs work properly. (just an example)
I've only seen one package that mandated a newer cups (in my example) and that was the source.
The problem is that the gentoo devs got lazy and started putting a dependency in the ebuild
which just happens to match up to what version of said package they themselves are running.
It's understandable but IMO, it's pure laziness.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
saellaven
l33t
Joined: 23 Jul 2006
Posts: 646
|
| Posted: Thu Dec 03, 2015 7:21 pm Post subject: |
|
|
What now?
| Quote: |
From: William Hubbs <williamh <at> gentoo.org>
Subject: rfc: OpenRC public API definition
Newsgroups: gmane.linux.gentoo.devel
Date: 2015-12-03 17:36:51 GMT (1 hour and 40 minutes ago)
All,
I would like opinions on what is considered the public api of librc.
1) All definitions in rc.h, even though they are not formally documented
in man pages.
2) the definitions in rc.h which are documented in section 3 man pages.
I'm bringing this up, because I am looking at redesigning one of the
undocumented functions soon, and the redesign will definitely break
things if people are using the function outside of OpenRC.
Thoughts? |
|
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Thu Dec 03, 2015 7:35 pm Post subject: |
|
|
| saellaven wrote: | | What now? |
saellaven ... that's a developer speaking, please pay attention ... roltfl.
best ... khay |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Thu Dec 03, 2015 7:59 pm Post subject: |
|
|
| saellaven wrote: | | What now? |
I'm going to guess we'll see stupidity raised to a fine art.
It's typical windows mentality though, "just throw all the binaries in one big pile".
The way that sysd is growing it'll probably subsume most binaries anyway.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
madjestic
n00b
Joined: 10 Oct 2013
Posts: 52
|
| Posted: Thu Dec 03, 2015 9:58 pm Post subject: |
|
|
| Anon-E-moose wrote: | Most of the ">=", ">", "<" <pkgname-pkgversion> in ebuilds are relatively new inventions (last year or so).
The problem is that the gentoo devs got lazy and started putting a dependency in the ebuild
which just happens to match up to what version of said package they themselves are running.
It's understandable but IMO, it's pure laziness. |
Should not users participate in the process and offset some simpler devs responsibilities, such as reporting suboptimal bound condictions? Help devs to do work on stability and features, rather than dedicating devs time to ensuring that bounds are perfectly correct - is that a bad thing? |
|
| Back to top |
|
|
gwr
Apprentice
Joined: 19 Nov 2014
Posts: 194
|
| Posted: Thu Dec 03, 2015 11:24 pm Post subject: |
|
|
| saellaven wrote: | What now?
| Quote: |
From: William Hubbs <williamh <at> gentoo.org>
Subject: rfc: OpenRC public API definition
Newsgroups: gmane.linux.gentoo.devel
Date: 2015-12-03 17:36:51 GMT (1 hour and 40 minutes ago)
All,
I would like opinions on what is considered the public api of librc.
1) All definitions in rc.h, even though they are not formally documented
in man pages.
2) the definitions in rc.h which are documented in section 3 man pages.
I'm bringing this up, because I am looking at redesigning one of the
undocumented functions soon, and the redesign will definitely break
things if people are using the function outside of OpenRC.
Thoughts? |
|
Is this a joke? Is he honestly asking if functions in a header file are considered part of an API?
Edit: Typo. |
|
| Back to top |
|
|
Yamakuzure
Advocate
Joined: 21 Jun 2006
Posts: 2284
Location: Adendorf, Germany
|
| Posted: Fri Dec 04, 2015 8:00 am Post subject: |
|
|
What are definitions in an includable header if not API? And what has this to do with "throwing binaries into a big pile"? Binaries != Header files. And what is the major difference between a Header having 20 definitions and a header having five includes with four definitions each? 
_________________
Important German:- "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
- "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
|
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri Dec 04, 2015 12:30 pm Post subject: |
|
|
| steveL wrote: | | Hmm kmod and nfs-utils may need patching, after review for lunacy. Don't suppose you've got bug ids? A summary from you as to issue would still be much appreciated, either way. |
| khayyam wrote: | | steve ... I don't think they require patching, the issue with nfs-utils is specific wrt changes to 'netmount' (the entire 'discussion' leading up to the recent '2015-10-07 openrc 0.18 localmount and netmount changes' news item). Here's the bug, the upshot of which is dependencies (ie, whether netmount can depend on net-fs/nfs-utils being installed ... or not), and so the roles of netmount, nfsclient, etc, what is doing what, to whom, and in what lavatory. |
Oh man, I lost far too much time yesterday, catching up with what's been going on.
Frankly I feel like I've lost the will to live; I'll discuss specifics when I've got some gusto back.
One good thing is, there was a commit in 2009 where Roy removed all redundant braces. I can't find it now, but it makes me feel much better about the shell issue. (we had a rather bull-headed discussion about it after G-UK a few years ago..;)
OFC thereafter you get the Gentoo lol-bashish style infecting the codebase again, but it means the base point is clean, and doesn't need me to do that commit, along with all the attendant issues pulling in later ones.
So that's a real bonus, in terms of saving implementation time.
| Quote: | | As far as kmod is concerned, other than the mask being simply my avoidance of "<sys-apps/openrc-0.13 is blocking" I'm rather more vague ... I'm fairly sure it relates to init.d/modules itself (rather than kmod), but I can't find anything in the Changelog other than "adjust the openrc blocker to !<0.13.8" ... and I'm not having any luck finding a bug that provides the reasoning behind it. |
What happens if you remove the block in local overlay? (On a test system, ofc; presuming the package makes any sense on your setup.) |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Fri Dec 04, 2015 12:52 pm Post subject: |
|
|
| steveL wrote: | | Quote: | | As far as kmod is concerned, other than the mask being simply my avoidance of "<sys-apps/openrc-0.13 is blocking" I'm rather more vague ... I'm fairly sure it relates to init.d/modules itself (rather than kmod), but I can't find anything in the Changelog other than "adjust the openrc blocker to !<0.13.8" ... and I'm not having any luck finding a bug that provides the reasoning behind it. |
What happens if you remove the block in local overlay? (On a test system, ofc; presuming the package makes any sense on your setup.) |
Probably not much, based on my doing it with a few other packages.
But I always glance at the source code to see if they require a particular version or it's just generic, ie any version of the package.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Fri Dec 04, 2015 1:39 pm Post subject: |
|
|
| gwr wrote: | | saellaven wrote: | What now?
| Quote: |
From: William Hubbs <williamh <at> gentoo.org>
Subject: rfc: OpenRC public API definition
Newsgroups: gmane.linux.gentoo.devel
Date: 2015-12-03 17:36:51 GMT (1 hour and 40 minutes ago)
All,
I would like opinions on what is considered the public api of librc.
1) All definitions in rc.h, even though they are not formally documented
in man pages.
2) the definitions in rc.h which are documented in section 3 man pages.
I'm bringing this up, because I am looking at redesigning one of the
undocumented functions soon, and the redesign will definitely break
things if people are using the function outside of OpenRC.
Thoughts? |
|
Is this a joke? Is he honestly asking if functions in a header file are considered part of an API?
Edit: Typo. |
That's not what he is asking. He is asking where breakage is acceptable
| Quote: | | Are all functions in a header part of an official API or only those with documentation. |
- personally... you expose it, its official
It appears he wants to "break" something but as it is part of the undocumented set he is querying exposure
The real question is why is there a lack of documentation coverage.
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri Dec 04, 2015 2:42 pm Post subject: |
|
|
| steveL wrote: | | What happens if you remove the [kmod] block [against openrc <0.13.18] in local overlay? (On a test system, ofc; presuming the package makes any sense on your setup.) |
| Anon-E-moose wrote: | Probably not much, based on my doing it with a few other packages.
But I always glance at the source code to see if they require a particular version or it's just generic, ie any version of the package. |
Glad to hear it; that's what I wanted to check with you, and is what I'd expect from a distribution developer.
Correct dependencies make ebuilds more useful in isolation, which is the point of a shared effort: to be useful.
Oh here's that commit I was talking about above.
A week before, there was this one trying it then the big one above, followed by this one (with a commit in-between). Have to admit, I don't like the lack of quoting in init.d/devfs.in, even though I understand that args are from a space-separated list (set -- $x); it just makes me twitch, based on (seeing others) being shouted at so many times in #bash. It's potentially globbed, and that makes me even more dubious. (Yes I know, I'm being paranoid: it keeps my scripts robust and reusable.)
So around there is a good base-point for me, at least.
I can't help feeling we shouldn't need to test [ "$RC_UNAME" = Linux ] at runtime; it should be part of the preprocessing that handles @subst@.
Does that seem sane?
I'd be much happier setting up "$RC_SH", and being able to test it in initscripts; though in general we should just be able to use SHELL, I don't know if there's any weird interaction with the options available. Nor is it mandated by POSIX, afaik, though it's mentioned as a common variable set by interpreters and applications. |
|
| Back to top |
|
|
gwr
Apprentice
Joined: 19 Nov 2014
Posts: 194
|
| Posted: Fri Dec 04, 2015 3:12 pm Post subject: |
|
|
| Naib wrote: |
That's not what he is asking. He is asking where breakage is acceptabl. |
That may have been the motivation, but it is not what he asked.
| Quote: | | I would like opinions on what is considered the public api of librc. |
He is clearly asking what qualifies as part of a (public) API. |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Fri Dec 04, 2015 3:41 pm Post subject: |
|
|
| gwr wrote: | | Naib wrote: |
That's not what he is asking. He is asking where breakage is acceptable. |
That may have been the motivation, but it is not what he asked.
| Quote: | | I would like opinions on what is considered the public api of librc. |
He is clearly asking what qualifies as part of a (public) API. |
Now take the entire statement so that context can be seen. He is asking whether undocumented api should be classed as public api. And that is exactly what is being asked, not what you read.
Now compare that to what you originally twisted it to be
| Quote: | | is this a joke? Is he honestly asking if functions in a header file are considered part of an API? |
twisting what was stated to perpetuate a stance does not help... Whether the question should have been asked in the 1st place doesn't change this
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
gwr
Apprentice
Joined: 19 Nov 2014
Posts: 194
|
| Posted: Fri Dec 04, 2015 4:00 pm Post subject: |
|
|
| Naib wrote: | | He is asking whether undocumented api should be classed as public api. |
That's right. He's asking if things in a header file qualify as a (public) API.
Whether or not the header file is documented is irrelevant to the question of what constitutes an API. It doesn't become public when you write a magic text file for it. It becomes public when the header is available. That's what he should already know. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri Dec 04, 2015 4:00 pm Post subject: |
|
|
| William Hubbs wrote: | I would like opinions on what is considered the public api of librc.
..Thoughts? |
If you have to ask "what is the public API", you're so not qualified to maintain it.
I note in passing that Hubbs does not even bother to mention which function he's talking about, nor what "redesign" he has in mind.
That's lovely: nice and transparent, and open about intentions: just what a FLOSS developer should do; if only.
| gwr wrote: | | Is this a joke? Is he honestly asking if functions in a header file are considered part of an API? |
Yup.
| Naib wrote: | That's not what he is asking. He is asking where breakage is acceptable
| Quote: | | Are all functions in a header part of an official API or only those with documentation. |
- personally... you expose it, its official |
While we both agree with your answer, I personally am at a loss as to how you can possibly think you are not answering the same question gwr just read it as. Your answer is a rewording of exactly what gwr just said.
That the questioner does not know the difference between an API and a manpage, is neither here nor there; that he's responsible for said documentation simply makes it risible.
Feel free to witter on about people "twisting" things, while you avoid the points put to you directly, and simply carry on as if they were never said. Just don't be surprised and/or upset when we draw our own conclusions.
| Quote: | | It appears he wants to "break" something but as it is part of the undocumented set he is querying exposure |
He's done this before; he likes to use words like "undocumented" or "legacy" to present the insinuation that he's really doing the right thing, gosh-darn it, despite all the "legacy" code he has to wrestle with (or more accurately, avoid.)
| Quote: | | The real question is why is there a lack of documentation coverage. |
Yes, that's the burning issue on all our minds.. /s
Personally I'm more concerned at what god-foresaken "redesign" he's going to come out with, especially after all the corkers we've had recently, like reworking fstab in a way no actual admin wants, nor has asked for, or the idiotic "let's shove all binaries in one directory, but keep all those config files scattered across the hierarchy"; funnily enough all "because systemdbust" which is just what we want from the "lead" of openrc, the portable clean game-changer that got Gentoo past sysv-rc a decade ago.
Yeah right, let's play "catch-up" with an idiot design from people who think UNIX is a dirty-word, and never did any research before proclaiming themselves "kernel and userland experts", instead. |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Fri Dec 04, 2015 5:00 pm Post subject: |
|
|
I'm really a bit surprised that nobody has yet forked OpenRC.
I'm masking a lot of stuff to keep systemd at bay, but recognize that that is not a good long-term prospect. I've finally realized that I've given up on xdcmp, so that opens my options on display managers. The scary thing is that people seem to be dropping remote X support, at least by default, and that I absolutely need.
BTW, I've largely dropped off the face of the Earth, because my new employer (Lots of us were sold this summer) is more focused on hardware and has different policies. Time at home has been constrained lately, too.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
gwr
Apprentice
Joined: 19 Nov 2014
Posts: 194
|
| Posted: Fri Dec 04, 2015 6:49 pm Post subject: |
|
|
| depontius wrote: | | I'm really a bit surprised that nobody has yet forked OpenRC. |
It seems like a project with a pretty low commit rate. At least according to https://gitweb.gentoo.org/proj/openrc.git/log/ |
|
| Back to top |
|
|
saellaven
l33t
Joined: 23 Jul 2006
Posts: 646
|
| Posted: Fri Dec 04, 2015 7:27 pm Post subject: |
|
|
| gwr wrote: | | depontius wrote: | | I'm really a bit surprised that nobody has yet forked OpenRC. |
It seems like a project with a pretty low commit rate. At least according to https://gitweb.gentoo.org/proj/openrc.git/log/ |
It just works and isn't trying to replace 95% of the system. That's one of the benefits of simple tools with a defined interface that interconnect with each other... You know, that UNIX philosophy stuff that the systemd crowd hates.
That said, I don't trust williamh being in charge of it. He has absolutely no clue what he's doing and is just another one of lennart's self-proclaimed cabal. Then add his ignorance to the Gentoo Council, where the guy that doesn't know what a public API is, is making binding, non-appealable technical decisions that affect us all. |
|
| 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
