On 01/03/14 08:40, Steven J. Long wrote:
> On Sat, Mar 01, 2014 at 07:20:24AM +0200, Samuli Suominen wrote:
>> If only Portage had supported checking if files from /usr were used by
>> files installed to /
>> Hard to create check for every case, but something like libraries and NEEDED
>> entries (
On Fri, Feb 28, 2014 at 09:31:08PM -0600, William Hubbs wrote:
> On Fri, Feb 28, 2014 at 09:47:05PM -0500, Wyatt Epp wrote:
> > But let's be real here: if I install something and
> > want to configure its system-wide bits, the first place I go is ALWAYS
> > /etc. When I don't find it there, with t
On Sat, Mar 01, 2014 at 07:20:24AM +0200, Samuli Suominen wrote:
> If only Portage had supported checking if files from /usr were used by
> files installed to /
> Hard to create check for every case, but something like libraries and NEEDED
> entries (bug 443590) would have been a start
> But there
On 03/01/2014 12:28 AM, Samuli Suominen wrote:
>
> On 01/03/14 04:55, Joshua Kinard wrote:
>> 3. Some profiles also override INSTALL_MASK, such as Gentoo/FreeBSD, because
>> systemd does not apply there.
>
> Wow. I don't think we should allow this without first having exactly
> what was suggested
On 01/03/14 04:55, Joshua Kinard wrote:
> 3. Some profiles also override INSTALL_MASK, such as Gentoo/FreeBSD, because
> systemd does not apply there.
Wow. I don't think we should allow this without first having exactly
what was suggested in this thread, a way of redefining the order
away from IN
On 01/03/14 02:18, Alon Bar-Lev wrote:
> On Sat, Mar 1, 2014 at 2:03 AM, William Hubbs wrote:
>> On Fri, Feb 28, 2014 at 09:57:15PM +, David Leverton wrote:
>>> William Hubbs wrote:
The reason the split happened is pretty straight forward, and every other
"justification" for continu
On 02/28/2014 7:47 PM, William Hubbs wrote:
> On Sat, Mar 01, 2014 at 12:24:02AM +, David Leverton wrote:
>> William Hubbs wrote:
>>> And I would argue that the maintenance cost of having separate /usr in a
>>> general sense is much higher than the benefit it provides.
>>
>> That's a legitimate
On Fri, 2014-02-28 at 19:18 +0200, Samuli Suominen wrote:
> On 28/02/14 19:01, Lars Wendler wrote:
> > On Fri, 28 Feb 2014 16:41:23 +0200 Samuli Suominen wrote:
> >
> >> On 28/02/14 16:41, Lars Wendler wrote:
> >>> On Fri, 28 Feb 2014 15:28:30 +0200 Samuli Suominen wrote:
> >>>
> It would be v
On Fri, Feb 28, 2014 at 09:47:05PM -0500, Wyatt Epp wrote:
> On Fri, Feb 28, 2014 at 7:47 PM, William Hubbs wrote:
> >
> > Patrick thinks that all configuration files belong in /etc, and what has
> > happened is, some packages are placing default configuration
> > files in /lib or /usr/lib and all
On Fri, Feb 28, 2014 at 09:06:36PM -0500, Rich Freeman wrote:
> On Fri, Feb 28, 2014 at 8:57 PM, Steev Klimaszewski wrote:
> > The way that it's been presented throughout this thread made it seem
> > like the network configurations when using e.g. networkd were being
> > stored in there.
>
> So,
On 02/28/2014 6:14 PM, Duncan wrote:
> hasufell posted on Fri, 28 Feb 2014 16:33:43 + as excerpted:
>
>> I remember a bug report where some user was messing with INSTALL_MASK
>> and "/usr/share/locale/" and didn't notice that he effectively removed
>> all language support... and started filing
On 02/28/2014 8:28 AM, Samuli Suominen wrote:
> It would be very helpful if INSTALL_MASK could be overriden from an
> ebuild, if user hasn't
> set otherwise.
> So it could be configured like USE_ORDER which is
> "env:pkg:conf:defaults:pkginternal:repo:env.d"
> So INSTALL_MASK_ORDER like "ebuild:${u
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/31/2013 06:43 PM, Andreas K. Huettel wrote:
> Am Dienstag, 31. Dezember 2013, 23:30:14 schrieb Mike Gilbert:
>> I have noticed that the arch profile directories (profiles/arch/$ARCH)
>> are not EAPI 5 capable. These profiles are inherited by both
On Fri, Feb 28, 2014 at 7:47 PM, William Hubbs wrote:
>
> Patrick thinks that all configuration files belong in /etc, and what has
> happened is, some packages are placing default configuration
> files in /lib or /usr/lib and allowing them to be overridden by files
> with the exact same names and
On Fri, Feb 28, 2014 at 8:57 PM, Steev Klimaszewski wrote:
> The way that it's been presented throughout this thread made it seem
> like the network configurations when using e.g. networkd were being
> stored in there.
So, with the new udev what I gather is:
1. Config settings (the stuff you're
On Fri, 2014-02-28 at 19:32 -0600, William Hubbs wrote:
> On Fri, Feb 28, 2014 at 07:09:08PM -0600, Steev Klimaszewski wrote:
> > I'm not exactly a fan of systemd, though I know it has some uses, and
> > I'm still curious as to why it installs/stores *configuration* data
> > in /lib - if only from
On Fri, Feb 28, 2014 at 07:09:08PM -0600, Steev Klimaszewski wrote:
> I'm not exactly a fan of systemd, though I know it has some uses, and
> I'm still curious as to why it installs/stores *configuration* data
> in /lib - if only from an upgrade point of view, we back up /etc, we
> back up /home -
On Fri, Feb 28, 2014 at 8:09 PM, Steev Klimaszewski wrote:
> Please keep in mind that not every device that runs Gentoo has the
> ability to just pop new storage in with more space. The Beaglebone
> Black has 2GB eMMC.
Hence the reason I suggested that embedded systems are a perfect case
where I
On Fri, 2014-02-28 at 10:31 -0500, Rich Freeman wrote:
>
> I think using INSTALL_MASK to kill a few inodes that probably don't
> even have extents using a sledgehammer to kill a fly, and if you put
> some holes in your walls in the process I_TOLD_YOU_SO. However, I
> won't tell people they can't
On Sat, Mar 01, 2014 at 12:24:02AM +, David Leverton wrote:
> William Hubbs wrote:
> > And I would argue that the maintenance cost of having separate /usr in a
> > general sense is much higher than the benefit it provides.
>
> That's a legitimate point (not that I necessarily agree or disagree
William Hubbs wrote:
And I would argue that the maintenance cost of having separate /usr in a
general sense is much higher than the benefit it provides.
That's a legitimate point (not that I necessarily agree or disagree as
I'm not the one who's tried to make it work) - perhaps I should have
On Sat, Mar 1, 2014 at 2:03 AM, William Hubbs wrote:
>
> On Fri, Feb 28, 2014 at 09:57:15PM +, David Leverton wrote:
> > William Hubbs wrote:
> > > The reason the split happened is pretty straight forward, and every other
> > > "justification" for continuing it was come up with after the fact.
On Fri, Feb 28, 2014 at 09:57:15PM +, David Leverton wrote:
> William Hubbs wrote:
> > The reason the split happened is pretty straight forward, and every other
> > "justification" for continuing it was come up with after the fact.
>
> I keep hearing this, but I really don't see how it's relev
Dnia 2014-02-28, o godz. 15:28:30
Samuli Suominen napisał(a):
> It would be very helpful if INSTALL_MASK could be overriden from an
> ebuild, if user hasn't
> set otherwise.
> So it could be configured like USE_ORDER which is
> "env:pkg:conf:defaults:pkginternal:repo:env.d"
> So INSTALL_MASK_ORDE
hasufell posted on Fri, 28 Feb 2014 16:33:43 + as excerpted:
> I remember a bug report where some user was messing with INSTALL_MASK
> and "/usr/share/locale/" and didn't notice that he effectively removed
> all language support... and started filing random bug reports. Took
> quite a while be
William Hubbs wrote:
The reason the split happened is pretty straight forward, and every other
"justification" for continuing it was come up with after the fact.
I keep hearing this, but I really don't see how it's relevant. I'm sure
you'll find lots of things in your life that you use for so
On Fri, Feb 28, 2014 at 03:59:35PM +, hasufell wrote:
*snip*
> Despite that... the answer is already here:
> http://devmanual.gentoo.org/general-concepts/filesystem/index.html
>
> > Gentoo does not consider the Filesystem Hierarchy Standard to be an
> > authoritative standard, although much
On Fri, Feb 28, 2014 at 10:59 AM, hasufell wrote:
> Despite that... the answer is already here:
> http://devmanual.gentoo.org/general-concepts/filesystem/index.html
>
>> Gentoo does not consider the Filesystem Hierarchy Standard to be an
>> authoritative standard, although much of our policy coinc
On 28/02/14 19:01, Lars Wendler wrote:
> On Fri, 28 Feb 2014 16:41:23 +0200 Samuli Suominen wrote:
>
>> On 28/02/14 16:41, Lars Wendler wrote:
>>> On Fri, 28 Feb 2014 15:28:30 +0200 Samuli Suominen wrote:
>>>
It would be very helpful if INSTALL_MASK could be overriden from an
ebuild, if
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 28/02/14 12:01 PM, Lars Wendler wrote:
> On Fri, 28 Feb 2014 16:41:23 +0200 Samuli Suominen wrote:
>>
>> You should stop attacking people. Period.
>
> Once you stop trying to make things worse in Gentoo I will
> consider stopping my attacks... s
On Fri, 28 Feb 2014 16:41:23 +0200 Samuli Suominen wrote:
>
>On 28/02/14 16:41, Lars Wendler wrote:
>> On Fri, 28 Feb 2014 15:28:30 +0200 Samuli Suominen wrote:
>>
>>> It would be very helpful if INSTALL_MASK could be overriden from an
>>> ebuild, if user hasn't
>>> set otherwise.
>>> So it could
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Ian Stakenvicius:
> On 28/02/14 11:17 AM, Thomas D. wrote:
>> Hi,
>
>> Ian Stakenvicius wrote:
>>> That said, what we could do (if this isn't done already) is
>>> have portage automatically elog or ewarn what files are
>>> excluded from the system o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 28/02/14 11:17 AM, Thomas D. wrote:
> Hi,
>
> Ian Stakenvicius wrote:
>> That said, what we could do (if this isn't done already) is have
>> portage automatically elog or ewarn what files are excluded
>> from the system on merge time due to the
Hi,
Ian Stakenvicius wrote:
> That said, what we could do (if this isn't done already) is have
> portage automatically elog or ewarn what files are excluded from
> the system on merge time due to the INSTALL_MASK. At least that
> way, users would be able to see in the log what files were removed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Samuli Suominen:
>
> On 28/02/14 13:15, Patrick Lauer wrote:
>> On 02/27/2014 09:08 PM, Anthony G. Basile wrote:
>>> Hi everyone,
>>>
>>> I'm putting the call out there for any agenda items for the
>>> next Council meeting, which will be held on Ma
On Fri, Feb 28, 2014 at 9:44 AM, Samuli Suominen wrote:
> I completely agree using INSTALL_MASK is 100% responsibility of the user
> setting it, it's like blind 'rm -f', but some people
> don't agree and keep attacking me.
> I'm using the word attacking because it's constant, relentless,
> repeati
On 28/02/14 17:24, Anthony G. Basile wrote:
> On 02/28/2014 08:28 AM, Samuli Suominen wrote:
>> It would be very helpful if INSTALL_MASK could be overriden from an
>> ebuild, if user hasn't
>> set otherwise.
>> So it could be configured like USE_ORDER which is
>> "env:pkg:conf:defaults:pkginternal
On 02/28/2014 08:28 AM, Samuli Suominen wrote:
It would be very helpful if INSTALL_MASK could be overriden from an
ebuild, if user hasn't
set otherwise.
So it could be configured like USE_ORDER which is
"env:pkg:conf:defaults:pkginternal:repo:env.d"
So INSTALL_MASK_ORDER like "ebuild:${user's own
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 28/02/14 09:59 AM, hasufell wrote:
> Samuli Suominen:
>> It would be very helpful if INSTALL_MASK could be overriden from
>> an ebuild, if user hasn't set otherwise. So it could be
>> configured like USE_ORDER which is
>> "env:pkg:conf:defaults
On 28/02/14 16:59, hasufell wrote:
> Samuli Suominen:
> > It would be very helpful if INSTALL_MASK could be overriden from
> > an ebuild, if user hasn't set otherwise. So it could be configured
> > like USE_ORDER which is
> > "env:pkg:conf:defaults:pkginternal:repo:env.d" So
> > INSTALL_MASK_ORDER
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Samuli Suominen:
> It would be very helpful if INSTALL_MASK could be overriden from
> an ebuild, if user hasn't set otherwise. So it could be configured
> like USE_ORDER which is
> "env:pkg:conf:defaults:pkginternal:repo:env.d" So
> INSTALL_MASK_ORD
On 28/02/14 16:18, Tom Wijsman wrote:
> On Fri, 28 Feb 2014 15:28:30 +0200
> Samuli Suominen wrote:
>
>> It would be very helpful if INSTALL_MASK could be overriden from an
>> ebuild, ...
> What is the intended goal? Can you give an example?
- User has INSTALL_MASK="/lib/systemd"
- Ebuild has IN
On 28/02/14 16:41, Lars Wendler wrote:
> On Fri, 28 Feb 2014 15:28:30 +0200 Samuli Suominen wrote:
>
>> It would be very helpful if INSTALL_MASK could be overriden from an
>> ebuild, if user hasn't
>> set otherwise.
>> So it could be configured like USE_ORDER which is
>> "env:pkg:conf:defaults:pkg
On Fri, 28 Feb 2014 15:28:30 +0200 Samuli Suominen wrote:
>It would be very helpful if INSTALL_MASK could be overriden from an
>ebuild, if user hasn't
>set otherwise.
>So it could be configured like USE_ORDER which is
>"env:pkg:conf:defaults:pkginternal:repo:env.d"
>So INSTALL_MASK_ORDER like "ebu
On 03/01/2014 12:28 AM, Samuli Suominen wrote:
> It would be very helpful if INSTALL_MASK could be overriden from an
> ebuild, if user hasn't
> set otherwise.
> So it could be configured like USE_ORDER which is
> "env:pkg:conf:defaults:pkginternal:repo:env.d"
> So INSTALL_MASK_ORDER like "ebuild:${
On Fri, 28 Feb 2014 15:28:30 +0200
Samuli Suominen wrote:
> It would be very helpful if INSTALL_MASK could be overriden from an
> ebuild, ...
What is the intended goal? Can you give an example?
Ebuilds can already clean out their own image during install; as for
installing an INSTALL_MASK file,
It would be very helpful if INSTALL_MASK could be overriden from an
ebuild, if user hasn't
set otherwise.
So it could be configured like USE_ORDER which is
"env:pkg:conf:defaults:pkginternal:repo:env.d"
So INSTALL_MASK_ORDER like "ebuild:${user's own INSTALL_MASK}"
This would be very helpful in pre
47 matches
Mail list logo
