| View previous topic :: View next topic |
| Author |
Message |
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6148
Location: Dallas area
|
 Posted: Sun Apr 10, 2016 3:11 pm Post subject: |
 |
|
I keep forgetting that funtoo is also an option to rolling my own.
It has the best of gentoo, while keeping stupid ideas like this merge to a minimum.
D. Robbins may very well have the last laugh after all.
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
 |
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Apr 10, 2016 3:17 pm Post subject: |
|
|
Post to gentoo-project mailing-list if you (reasonably imo) think your concerns might get the developer-poison treatment on gentoo-dev.
That way you can also address socio-political aspects as well, since that is what the list was originally set up for (I know, because I was closely involved with the original discussion to set it up): the "non-technical" aspects of development, related to current technical discussion.
Techies are usually full of crap when it comes to socio-political matters. (Preferring instead to take the lazy thinking/cognitive dissonance shortcut of telling themselves that pretending they're "apolitical" sets them "above" such concerns, instead of at their mercy.)
OFC that is also why gentoo-dev has always been open to all as well: in order to force developers to gain wider community consensus for any wacky ideas, and thus avoid just following the loudest voice or three in the echo-chamber, whilst stumbling across traps which are obvious to those with greater experience of falling into them and getting out again. |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3433
|
| Posted: Sun Apr 10, 2016 4:27 pm Post subject: |
|
|
| Quote: | | (...) merge /bin into /usr/bin you might as well merge /lib{,32,64} into /usr/lib{,32,64} (...) |
Move from / to /usr, right? Why not move those files from /usr/ to / instead? I wonder where is goes. Quite frankly I can imagine a few use cases for separate /usr though. Shadowing minimal boot-time tools with more powerful counterparts for example. Like in busybox for boot vs coreutils for users.
On the other hand, if we put enough files in /usr, (e.g. /usr/etc, /usr/var ... ), we may just as well extract initramfs onto /boot, change a line or two in the init script, and suddenly.... Hey, separate /usr is supported again  |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6065
Location: Removed by Neddy
|
| Posted: Sun Apr 10, 2016 4:44 pm Post subject: |
|
|
| szatox wrote: | | Quote: | | (...) merge /bin into /usr/bin you might as well merge /lib{,32,64} into /usr/lib{,32,64} (...) |
Move from / to /usr, right? Why not move those files from /usr/ to / instead? I wonder where is goes. Quite frankly I can imagine a few use cases for separate /usr though. Shadowing minimal boot-time tools with more powerful counterparts for example. Like in busybox for boot vs coreutils for users.
On the other hand, if we put enough files in /usr, (e.g. /usr/etc, /usr/var ... ), we may just as well extract initramfs onto /boot, change a line or two in the init script, and suddenly.... Hey, separate /usr is supported again |
exactly  it has a whiff of change for change sake. I am all for change if it enables solving complications or facilitating a cleaner overall solution down the road ... but this?
Is it to make /<root> less cluttered? yet the freedesktop initiative placed a /run and a /media when we have a /var/run and a /mnt
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Sun Apr 10, 2016 4:56 pm Post subject: |
|
|
| Anon-E-moose wrote: | I keep forgetting that funtoo is also an option to rolling my own.
It has the best of gentoo, while keeping stupid ideas like this merge to a minimum.
D. Robbins may very well have the last laugh after all. |
I'm not sure an alternative distro would react well to a sudden influx of Gentoo refugees, but I'd keep the option open as a last resort.
One thing that's clear though: WH has a reality distortion field, and no amount of outrage, panic, reasoned arguments or the word "No" has, to date, caused him to change or even consider the destructive course he's sending our distro in. We should be thinking about taking defensive measures at this point to isolate the damage he can cause.
Which is an ever-expanding mountain to climb, because with this filesystem assault he now has his fingers in every pie: all the init/rc systems in portage have already been covertly broken to support this current agenda. Even sys-process/runit::gentoo doesn't work with separate /usr! Upstream's code does. He's gone *out of his way* to break that, and it's obvious he doesn't actually use it because he sits on bugs with patches for things like "shell doesn't function from vt login" for months on end. (BTW, is there anyone using s6 that can chime in here? Curious if that ebuild's been similarly lobotomised.) |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Apr 10, 2016 5:04 pm Post subject: |
|
|
| depontius wrote: | | Is there any way a /usr merge could be made optional, say a USE flag or other portage directive? |
The way to do that, is to continue with what we already had decades ago.
ATM anyone can merge however they like; we've seen Duncan's use-case being lauded as an example of how this must be a good idea, when in fact all it shows is that the extant setup is already flexible enough to do whatever people want.
For instance, we have a couple of directories moved to rootfs from /usr, precisely so agetty and bash can work from rootfs, since they otherwise have deliberately tight linkage. (Portage is fine with this.)
OFC I'd rather see that as a default, since it makes it easy to do whatever else including an initrd[1], than forcing everyone to the same deranged idea of squashing it all into one humongous directory.
| Quote: | | If pressed hard, perhaps I don't mind merging /bin and /usr/bin - THAT badly, because I've read enough LKML to understand that to some, initrd is the new /. |
I do: just because a bunch of Windoze rejects doesn't grok UNIX is no reason to pander to their ill-conceptions.
| Quote: | | But merging sbin content into bin is just not a good idea at all, and to me that is a bigger mistake than the /usr mess. |
It's complete nonsense, agreed.
| Naib wrote: | | keeping the sbin's out of the discussion for now as that is quite derp... |
No. That's the point: complete derp is being foisted upon us, by people who clearly do not know what they are doing, or at best behave like corporate shills.
| Quote: | | if you merge /bin into /usr/bin you might as well merge /lib{,32,64} into /usr/lib{,32,64} |
And if we just ignore these asshats, we can continue using UNIX.
| Quote: | | The only argument for the (gentoo) merge appears to be around portage collision... but if a file resides in /bin and a file by the same name resides in /usr/bin there is no collision... |
Yup; more derp that a moment's reflection would have brought to mind.
The usual answer to "this is derp" from this crowd, appears to be "that's because UNIX is bad, POSIX sucks, and we don't understand why after being rejected from Windoze, we were also rejected by the Linux kernel crowd and the RT-audio crowd, so we're full of venom, but hey we can do javascript and that works on the desktop, so listen to us: we're the kernel and userland experts. Look, shiny! (here's the next pseudo-science bit.)"
[1] This point (that a root split actually makes initrd work easier) was made on the mailing-list, several years ago, when Hubbs and mgorny were first blathering on about split-usr (the lack of support for split usr without initramfs had no technical basis, and was totally spurious.) OFC, no-one on the gentoo-dev list was interested in collaboration between the "camps", which is an artifical distinction in any case since you might use an initrd on one system, and not on another.
Last edited by steveL on Sun Apr 10, 2016 5:19 pm; edited 2 times in total |
|
| Back to top |
|
|
tld
Veteran
Joined: 09 Dec 2003
Posts: 1845
|
| Posted: Sun Apr 10, 2016 5:15 pm Post subject: |
|
|
| saellaven wrote: | | So yes, I will blame the systemd devs... as they're the ones that want to turn linux into Windows. the user merge is their way of making linux into c:\windows. |
Of course the irony is that in Windows, basically all non-Microsoft applications are expected to install their binaries in their own directories under God-awful paths with spaces in directory name...requiring a $PATH thousands of characters long which must be edited using a non-expandable GUI text box about 2" long...should I go on?...
Maybe we should emulate all that was well while we're at it. After copying the approach of the f***ing "Windows Event Log" frankly it wouldn't surprise me. |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sun Apr 10, 2016 6:33 pm Post subject: |
|
|
| depontius wrote: | | Why don't we put up a poll about the whole /usr merge thing? |
| khayyam wrote: | | before doing this shouldn't we insist that the case *for* present the reasons why this is a good idea? I'm not seeing that, so any poll would, in my mind, circumvent such a necessary presentation of fact. |
| depontius wrote: | | Won't disagree, but from what I can see, there is no mechanism for that insistence. |
depontius ... it was more a case of what the poll represents. We haven't had a presentation of fact, so why do we need a poll. We could (hypothetically) have a poll on any number of abstract changes but unless a case is made for why that change is needed/necessary, and what benefits come from it, then a poll does nothing but suggest that such a change might go ahead simply based on the poll rather than the case made for the change. In the case of /usr merge that presentment of fact is the freedesktop.org document, and those facts are either askew, or not relevant to gentoo (the difference in release cycles, and so roll-out, being one relevant difference).
| depontius wrote: | | I really don't know how this beast called Gentoo is governed, and I suspect most in the forums know less than me. |
Perhaps the rules (or governance model) gentoo operates under thread can answer to that. I would say (again) that basically what we have is a system whereby the stated rules in the charter (specifically "for the community, by the community", and "independence") are second tier imperatives to the actual mode of governance, "developers do as they please", "the community isn't paying for their work", etc. The problem is that the latter effectively hides behind the former, so while the impression is given that "the community" is the central organising power, it is the developers who in fact govern. This can only change by users insisting (one way or other) that developers take note, and that they challenge them in their decision making, but unfortunately there is no real mechanism for this, other than by using the discussion fora. As the above linked discussion shows, when such ideas are challenged a developer can quite as easily ignore it, leave the discussion, etc. That leaves the the gentoo foundation, they are the only power that can bring developers to heel, and/or change things in such a way that developers become more answerable to the community (and/or provide the community with more of a role in the decision making process), and while that is not impossible, it would require a struggle to assert, and no doubt a lot of bad blood.
best ... khay |
|
| Back to top |
|
|
truekaiser
l33t
Joined: 05 Mar 2004
Posts: 804
|
| Posted: Sun Apr 10, 2016 7:32 pm Post subject: |
|
|
| And here i thought gentoo would be somewhat safe from the SystemD madness.. Can't we just give him the boot? Tell him to take a hike? |
|
| Back to top |
|
|
saellaven
l33t
Joined: 23 Jul 2006
Posts: 654
|
| Posted: Sun Apr 10, 2016 7:53 pm Post subject: |
|
|
| truekaiser wrote: | | And here i thought gentoo would be somewhat safe from the SystemD madness.. Can't we just give him the boot? Tell him to take a hike? |
The following is my opinion, based on my observations over the last several years since williamh joined the Council and immediately pushed it to officially eliminate support for a separate /usr.
There is a small, but fervent, group of gentoo devs that are hell bent on following RedHat, Lennart, et al, down the path they want to go. Some of them are very active gentoo devs, whom, through their exuberance and willingness to stomp all over the tree, have frustrated and run off some other formerly key devs. As zealots for their cause, they largely maintain the singular focus of foisting their beliefs on the rest of the community. Active as they are, it was easier to co-opt an existing distro, particularly one that allows votes on leadership and any dev to, essentially, stomp all over some other dev's territory (ie, committing changes to a package another dev maintains, whether they particularly want them or not).
Because most of the other gentoo devs are generalists or only care about their niche interests, it has allowed this group to take a significant, and sometimes, commanding, amount of control over the distro. When the separate /usr issue came up, the Council didn't bother to research it, they just trusted williamh, whom it can be shown knew about the existing patches to maintain support for a separate /usr, but went out of his way to ignore the patches and, certainly didn't inform his other Council members about the possibility. Having faith in williamh, as lead (though certainly not the original author) of openrc and a member of the systemd team, the Council blindly went along with him.
As I mentioned then, and as has been brought up now, the mandatory initramfs issue was a key predicate for eventually pushing the usr merge idea... you'll also note the decision to install files that may be required by openrc into /usr/lib/systemd, which makes it harder to simply mask that directory. You'll also note that it is under /usr instead of being under /etc (or / in general), with the argument being that is how the systemd upstream does it... and thus, even though gentoo is the openrc upstream, even openrc must bow to the wishes of RedHat/Lennart/systemd. In fact, the argument for removing support for a separate /usr came from the same crowd. Repeatedly, we see attempts to limit the flexibility of gentoo based on the limitations of the group, both upstream and internal to gentoo, that want to push systemd on the rest of us.
I've long stated that williamh and the rest of the Council that refused to do their job when considering the matter need to be removed from their positions of power. And they don't only control the Council, but ComRel (or whatever it is being called now) and other bodies as well. The one place they don't have a strong foothold, is, the one group that has all the legal power, and that is the Gentoo Trustees. However, the Trustees seem reluctant to do anything, and, in fact, have talked about formally granting power to the Council over technical matters anyway.
In the end, the people that can do something don't really seem to want to, while the fervent zealots continue to merrily stomp all over our distro and the ideals that it was originally founded upon. The one action that we, as the gentoo users, can do, is go through the process of becoming devs, jumping through all of the games to do so, assuming the current devs looking to exploit gentoo would even let us get that far, with the primary purpose of forcing them out of the Council, as the devs are the sole group that control who creates the technical mandates for the distro. |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6065
Location: Removed by Neddy
|
| Posted: Sun Apr 10, 2016 8:12 pm Post subject: |
|
|
before you lot get your knickers in a twist with what William is proposing ... its been pretty much shot down by every dev on the ML (one user is advocating it and cites sysd rationale: https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/) .... ranging from citing the linux foundation baselayout (and /bin,/sbin/lib/ for single user and no mount...), some sanity with WTF do you do this on a live system without hozing it
--edit--
That sysd rationale still had an sbin so WTF is william advocating the merging of bin and sbin against?
--edit--
WTF... the citation from the sysd rationale, after the myth BS is a pottering email:
http://thread.gmane.org/gmane.linux.redhat.fedora.devel/155511/focus=155792
| Quote: |
b) The original definition of /sbin is fully obsolete (i.e. the "s" in
sbin stood originally for "static" binaries) |
It was system binaries...
_________________
| Quote: | | Removed by Chiitoo |
Last edited by Naib on Sun Apr 10, 2016 8:18 pm; edited 1 time in total |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54578
Location: 56N 3W
|
| Posted: Sun Apr 10, 2016 8:15 pm Post subject: |
|
|
saellaven,
| saellaven wrote: | | However, the Trustees seem reluctant to do anything, and, in fact, have talked about formally granting power to the Council over technical matters anyway. |
Citation please.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Apr 10, 2016 8:31 pm Post subject: |
|
|
| Naib wrote: | | before you lot get your knickers in a twist.. |
How about you simply stop trivialising and using demeaning language for any stance that you clearly don't get.
I refer you to the above case, where again, you tried to pretend that the overall problem is not the problem:
| Naib wrote: | | keeping the sbin's out of the discussion for now as that is quite derp... |
| steveL wrote: | | No. That's the point: complete derp is being foisted upon us, by people who clearly do not know what they are doing, or at best behave like corporate shills. |
It's not about whether we can collectively add enough weight of argument to shoot down the nonsense, so that developers can feel confident in rejecting ill-premised ideas.
It's about why we keep on having to, and how many times developers will go through this without simply calling crap "crap", and taking note of who keeps talking it, all in the name of "professional courtesy".
Apparatchiks work by constantly presenting the same crud over and over, until other people get bored of arguing; in the meantime there's the weight of all that "evidence", and neophytes looking on don't know what to think, but have had their heads filled with specious propaganda.
When decisions are made, they are made in an atmosphere poisoned by that same pollution, by people who don't really know what they're doing (but spend inordinate hours stating the obvious on mailing-lists in an effort to appear "statesmanlike" instead.)
I mean there must be something good about systemdbust, surely? It can't really just be the constantly changing and unstable output of two guys (and their fanbois) stumbling their way round learning to code for UNIX, can it?
No, there's at least three nubs stumbling about.. ;p
And more importantly, there is a huge multinational conglomerate, pushing its agenda so it can provide "support" to corporations seeking to evade the GPL and "monetise" the rest of us.
It's not about computing: it's about control of users, so that they can be turned into a commodity and sold on.
By all means, avoid the subject you don't understand; just don't pretend it is irrelevant.
All we are talking about ultimately, is not wasting time with known-crap ideas (and the shills who keep on presenting them as kool-aid.) |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sun Apr 10, 2016 8:56 pm Post subject: |
|
|
| Lennart Poettering wrote: | | b) The original definition of /sbin is fully obsolete (i.e. the "s" in sbin stood originally for "static" binaries) |
... rotfl, and like other such "arguments" you repeat it enough and the truth of its origins becomes obscure.
best ... khay |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6065
Location: Removed by Neddy
|
| Posted: Sun Apr 10, 2016 9:22 pm Post subject: |
|
|
| khayyam wrote: | | Lennart Poettering wrote: | | b) The original definition of /sbin is fully obsolete (i.e. the "s" in sbin stood originally for "static" binaries) |
... rotfl, and like other such "arguments" you repeat it enough and the truth of its origins becomes obscure.
best ... khay |
exactly... Just change a definition so that the new definition can easily be refuted " since static-bin is redundant as 'everything' uses shared libs, we don't need sbin as it is now redundant"
He may honestly believe that ... But unless there is a canonical reference you now have to dismiss two things that are arbitrarily linked.
_________________
| Quote: | | Removed by Chiitoo |
Last edited by Naib on Mon Apr 11, 2016 11:48 am; edited 1 time in total |
|
| Back to top |
|
|
saellaven
l33t
Joined: 23 Jul 2006
Posts: 654
|
| Posted: Sun Apr 10, 2016 10:01 pm Post subject: |
|
|
| NeddySeagoon wrote: | saellaven,
| saellaven wrote: | | However, the Trustees seem reluctant to do anything, and, in fact, have talked about formally granting power to the Council over technical matters anyway. |
Citation please. |
I do believe you personally mentioned wanting to officially make the Council a formal, recognized entity for legal purposes since, currently, the Trustees are responsible even though they don't have control over the Council's decisions. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri Apr 22, 2016 12:02 am Post subject: |
|
|
| saellaven wrote: | | I do believe you personally mentioned wanting to officially make the Council a formal, recognized entity for legal purposes since, currently, the Trustees are responsible even though they don't have control over the Council's decisions. |
I don't think that's necessary, because the Trustees do not want to control Council decisions which fall under Council purview, ie technical direction. (Nor should they.)
The problem is where the Council takes on decisions which are decidedly not technical, such as appointing themselves ultimate arbiter over social disputes, or moderation across Gentoo, to put it another way.
No-one could reasonably argue that those are technical decisions, or that the Council has been selected for ability at social moderation, which is often political in the broad sense of the word.
Especially since developers have always prided themselves on the fact that the Council is chosen strictly to handle purely technical matters.
Granting the Council some sort of legal status under the Charter, would do nothing to change the fact that the Council acts ultra vires; it would only hasten the prospect of any legal action in a case where that were relevant (thus it is not in anyone's interest, the Trustees included.)
Personally I feel it would also lead to the demise of Gentoo as we know it: it's good that the devs are focussed solely on maintaining the tree, whereas asking them to take on legal responsibilities defeats the point of the split. (the most we'd get out of it, is even more apparatchiks.)
It would not ameliorate the situation, principally because it has got nothing to do with the actual problem, the solution to which is known and was agreed many years ago: to apply the same standards that user-channels maintain to developer ones, by using the same moderators that work so well on forums and IRC, and extending their remit to developer lists, along with stricter sanctions on developers and ex-developers.
The former because they are expected to hold to a higher standard than joe-user, as they represent the project and sign up to that standard; the latter because being evicted from the group for repeated, wilfully anti-social behaviour, should not mean an ex-developer can suddenly pop back as a poisonous user and continue to waste everyone's time.
Unfortunately that got spiked by developers, so now developers answer only to themselves when it comes to anti-social behaviour (and users are needlessly harassed and threatened with sanctions that are meant for developers.) That this is a blatant conflict of interest which no-one seems to notice or mind, only evinces further how unsuited they are to the task.
That is only natural, and unsurprising given a moment's thought.
I don't see much changing, because the developers are happy with the way things are, and the Trustees do not appear to have much time.
I sure as hell wouldn't want to try and get the developer-collective to see the light, so find it unsurprising Trustees don't fancy the task, either.
Although the Trustees are of course free to appoint moderators over social matters, and do whatever else they see fit to advance the purposes of the Foundation, as they are the only people with ultimate legal authority.
The Council does not exist, legally speaking, and even if it did, it would be acting under the aegis of Trustees, and would still have no remit over social matters, nor authority to interact with other legal entities, eg to negotiate contracts binding on the Foundation.
Getting developers to see that letting someone else do the moderation, is in fact in their own broader interests (and means they can avoid a whole chunk of work they don't actually enjoy, or are definitely unsuited to) would not be my idea of fun.
But then, I'm no good at moderation either. ;p |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54578
Location: 56N 3W
|
| Posted: Fri Apr 22, 2016 12:31 pm Post subject: |
|
|
saellaven,
I was trying to suggest that we need to find a way to slay the two headed monster that Gentoo has become. So we organise along the lines of a traditional corporation.
To do that, the authority/responsibility tree must be headed by a body with legal standing.
It can't 'just happen' as the current technical leadership has its own rules which are incompatible with the legal requirements that any corporation needs to follow.
Agreeing within Gentoo that the council answers to the trustees cannot happen without significant changes to the constitution of the council. So much so, that it would not be recognisable as the current council.
The trustees have a legal obligation to 'appoint competent persons'.
Lets dwell on that 'appoint competent persons' ... lots of questions follow but no answers.
Where do (council) elections fit into appointments?
The 'competent' requirement means anyone who can discharge the responsibilities of the role. That does not restrict appointments to Gentoo devs.
New Mexico law requires that two directors sit on all sub committees. It would be difficult to make a case that technical leadership was somehow not a sub-committee of the foundation governance process. Now we have an appointed technical leadership body that includes two trustees. That's just to keep in line with the law.
Its clear from the above that the resulting technical leadership body is not going to be constituted anything like the current council.
Now it gets more difficult. The foundation has its members, who get to vote in foundation matters. They are like share/stockholders That electorate excludes a large number of developers who currently vote for the council. Developer membership of the foundation is opt in not opt out.
Who gets to vote on such structural changes to Gentoo?
After that, it no longer makes sense that the technical leadership body look after any more than technical stuff.
Its a big change and it has to happen all in one go. Gentoo doesn't work that way. Change is incremental.
As an individual trustee, it makes me a bit nervous to be legally responsible for the council actions but to have no formal authority over those actions.
Still, if an American court wants to jail me, they need to extradite me from the UK first.
Referring to "the council" on IRC is much simpler than posting all of the above.
However, You are correct, my IRC session could have been interpreted the way you posted.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
1clue
Advocate
Joined: 05 Feb 2006
Posts: 2569
|
| Posted: Fri Apr 22, 2016 1:25 pm Post subject: |
|
|
| Don't most packages support prefixes for install paths? Surely there's a way to hook into that with portage. |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6065
Location: Removed by Neddy
|
| Posted: Fri Apr 22, 2016 1:33 pm Post subject: |
|
|
| 1clue wrote: | | Don't most packages support prefixes for install paths? Surely there's a way to hook into that with portage. |
If they don't the build process is patched to accommodate it...
Portage relies on it when a package is built
PORTAGE_TMPDIR
BUILD_PREFIX
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3433
|
| Posted: Fri Apr 22, 2016 3:28 pm Post subject: |
|
|
Good point about those prefixes.
Setting custom function to determine correct location for any package (or even any file) can't be that hard.
Say, there could be a hook executing a locally defined function that would check arbitrary parameters and decide on behalf of local admin (Err... local maintainer  ) which branch of the filesystem will host the files. E.g. definition like "if init -> /usr/ ; true -> /" would ensure separate /usr without initrd won't work |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Fri Apr 22, 2016 5:03 pm Post subject: |
|
|
The build prefixes have nothing to do with installation into /bin or /usr/bin and also cannot be used to hack that up locally: This would change also other paths nobody wants to change.
The "right" way to modify the corresponding prefixes is by passing corresponding paths to ./configure. You can do this locally with e.g. EXTRA_ECONF.
(I am assuming here that all packages which one might want to have in /bin or /sbin use a standard autotools-type ./configure file; I would be surprised if this is not the case for a package in /bin or /sbin).
So, in practice, all these things are technically probably not too hard to override locally. It is only a political decision which should be the defaults and how hard it is to change the defaults (i.e. whether one forces the hack with EXTRA_ECONF or whether one provides simply a USE-flag to the corresponding packages). |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6065
Location: Removed by Neddy
|
| Posted: Fri Apr 22, 2016 5:15 pm Post subject: |
|
|
but --prefix could be used if so needed I guess
_________________
| Quote: | | Removed by Chiitoo |
Last edited by Naib on Fri Apr 22, 2016 5:25 pm; edited 1 time in total |
|
| Back to top |
|
|
1clue
Advocate
Joined: 05 Feb 2006
Posts: 2569
|
| Posted: Fri Apr 22, 2016 5:17 pm Post subject: |
|
|
I'm just guessing here but this /usr merge discussion has been going on for some time, and I suspect most mainstream projects are building some sort of configuration into their projects. I'm pretty sure I built apache with some of this stuff back before systemd was ever anounced.
Surely if there is no discussion about this in upstream communities there should be. There are to pretty large camps on this issue, and it seem prudent to accommodate both groups. |
|
| Back to top |
|
|
1clue
Advocate
Joined: 05 Feb 2006
Posts: 2569
|
|
| 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
