Re: [gentoo-portage-dev] custom profiles?
On 03/14/2015 11:41 AM, Joakim Tjernlund wrote:
On Sat, 2015-03-14 at 11:08 -0700, Zac Medico wrote:
On 03/14/2015 09:12 AM, Joakim Tjernlund wrote:
On Wed, 2015-03-11 at 13:43 -0700, Zac Medico wrote:
On 03/11/2015 01:16 PM, Joakim Tjernlund wrote:
On Wed, 2015-03-11 at 10:56 -0700, Zac Medico wrote:
On 03/11/2015 08:48 AM, Joakim Tjernlund wrote:
On Sun, 2015-03-08 at 11:58 -0700, Zac Medico wrote:
On 03/08/2015 10:01 AM, Joakim Tjernlund wrote:
On Sun, 2015-03-08 at 15:47 +, Joakim Tjernlund wrote:
package.use/package.use.force is a bit different though:
cat /etc/portage/package.use/qemu
app-emulation/qemu vde -alsa -pulseaudio -bluetooth -opengl
qemu_user_targets_x86_64 xattr
virtfs
static-
user
#Needed by static-user
sys-libs/zlib static-libs
dev-libs/glib static-libs
sys-apps/attr static-libs
Moving this to package.use/package.use.force does not respect -alsa,
-pulseaudio, -opengl
all
flags which has a - on them, emerge wants to turn them on again.
Am I missing something?
Using portage 2.2.18
Appears one have to use package.use.mask for that.
cat package.use.mask
app-emulation/qemu alsa pulseaudio bluetooth opengl
It would be handy if one could use the same syntax as in
/etc/portage/package.use/qemu(-alsa -
opengl
etc.)
Jocke
Yes, the inverted use.mask logic can be confusing if you are not
familiar with it. The negative
flags
have a
special meaning within the context of of portage's incremental
stacking behavior, so they can
still
be
useful, though not in the same way that you you attempted to use them.
Just noticed that USE flags in profiles/package.use.mask override
everything so this
USE=thin emerge -av sys-fs/lvm2
will not turn on thin if thin is in profiles/package.use.mask
How can just change the default so a user can easily turn it on ?
Generally, setting the USE environment variable like that is poor practice,
because the setting will not
persist the next time that you rebuild the package. So, you should set the
flag in
I know, this was just an example to illustrate that it did not work.
/etc/portage/package.use. You can unmask the flag for lvm2 like this:
echo sys-fs/lvm2 -thin /etc/portage/profile/package.use.mask
You misunderstand, I have sys-fs/lvm2 thin in
/etc/portage/profile/package.use.mask
and I want a user to able to override this setting, using USE=.. or adding
it
to their local /etc/portage/package.use file/dir
There's no other way to negate a use mask than to use
/etc/portage/profile/{use.mask,package.use.mask} as I have described. I
don't think that it makes much sense to negate a use mask for a single
emerge invocation. If you want to do that, then why is the use flag
masked anyway?
--
Thanks,
Zac
Re: [gentoo-portage-dev] custom profiles?
On Sat, 2015-03-14 at 11:57 -0700, Zac Medico wrote:
On 03/14/2015 11:41 AM, Joakim Tjernlund wrote:
On Sat, 2015-03-14 at 11:08 -0700, Zac Medico wrote:
On 03/14/2015 09:12 AM, Joakim Tjernlund wrote:
On Wed, 2015-03-11 at 13:43 -0700, Zac Medico wrote:
On 03/11/2015 01:16 PM, Joakim Tjernlund wrote:
On Wed, 2015-03-11 at 10:56 -0700, Zac Medico wrote:
On 03/11/2015 08:48 AM, Joakim Tjernlund wrote:
On Sun, 2015-03-08 at 11:58 -0700, Zac Medico wrote:
On 03/08/2015 10:01 AM, Joakim Tjernlund wrote:
On Sun, 2015-03-08 at 15:47 +, Joakim Tjernlund wrote:
package.use/package.use.force is a bit different though:
cat /etc/portage/package.use/qemu
app-emulation/qemu vde -alsa -pulseaudio -bluetooth
-opengl qemu_user_targets_x86_64
xattr
virtfs
static-
user
#Needed by static-user
sys-libs/zlib static-libs
dev-libs/glib static-libs
sys-apps/attr static-libs
Moving this to package.use/package.use.force does not
respect -alsa, -pulseaudio, -
opengl
all
flags which has a - on them, emerge wants to turn them on
again.
Am I missing something?
Using portage 2.2.18
Appears one have to use package.use.mask for that.
cat package.use.mask
app-emulation/qemu alsa pulseaudio bluetooth opengl
It would be handy if one could use the same syntax as in
/etc/portage/package.use/qemu(-
alsa -
opengl
etc.)
Jocke
Yes, the inverted use.mask logic can be confusing if you are
not familiar with it. The
negative
flags
have a
special meaning within the context of of portage's
incremental stacking behavior, so they
can
still
be
useful, though not in the same way that you you attempted to
use them.
Just noticed that USE flags in profiles/package.use.mask override
everything so this
USE=thin emerge -av sys-fs/lvm2
will not turn on thin if thin is in profiles/package.use.mask
How can just change the default so a user can easily turn it on ?
Generally, setting the USE environment variable like that is poor
practice, because the setting will
not
persist the next time that you rebuild the package. So, you should set
the flag in
I know, this was just an example to illustrate that it did not work.
/etc/portage/package.use. You can unmask the flag for lvm2 like this:
echo sys-fs/lvm2 -thin /etc/portage/profile/package.use.mask
You misunderstand, I have sys-fs/lvm2 thin in
/etc/portage/profile/package.use.mask
and I want a user to able to override this setting, using USE=.. or
adding it
to their local /etc/portage/package.use file/dir
There's no other way to negate a use mask than to use
/etc/portage/profile/{use.mask,package.use.mask} as I
have described. I don't think that it makes much sense to negate a use mask
for a single emerge invocation.
If you want to do that, then why is the use flag masked anyway?
I am putting tougher a profile for my company where I want to specify default
USE flags for different apps/libs. Then a user who knows what he/she is doing
should be able to override these defaults. It is not possible as far
as I can tell to override negative USE flags or is there?
Jocke
Re: [gentoo-portage-dev] custom profiles?
On 03/14/2015 12:30 PM, Joakim Tjernlund wrote:
On Sat, 2015-03-14 at 11:57 -0700, Zac Medico wrote:
On 03/14/2015 11:41 AM, Joakim Tjernlund wrote:
On Sat, 2015-03-14 at 11:08 -0700, Zac Medico wrote:
On 03/14/2015 09:12 AM, Joakim Tjernlund wrote:
On Wed, 2015-03-11 at 13:43 -0700, Zac Medico wrote:
On 03/11/2015 01:16 PM, Joakim Tjernlund wrote:
On Wed, 2015-03-11 at 10:56 -0700, Zac Medico wrote:
On 03/11/2015 08:48 AM, Joakim Tjernlund wrote:
On Sun, 2015-03-08 at 11:58 -0700, Zac Medico wrote:
On 03/08/2015 10:01 AM, Joakim Tjernlund wrote:
On Sun, 2015-03-08 at 15:47 +, Joakim Tjernlund wrote:
package.use/package.use.force is a bit different though:
cat /etc/portage/package.use/qemu
app-emulation/qemu vde -alsa -pulseaudio -bluetooth -opengl
qemu_user_targets_x86_64
xattr
virtfs
static-
user
#Needed by static-user
sys-libs/zlib static-libs
dev-libs/glib static-libs
sys-apps/attr static-libs
Moving this to package.use/package.use.force does not respect
-alsa, -pulseaudio, -
opengl
all
flags which has a - on them, emerge wants to turn them on again.
Am I missing something?
Using portage 2.2.18
Appears one have to use package.use.mask for that.
cat package.use.mask
app-emulation/qemu alsa pulseaudio bluetooth opengl
It would be handy if one could use the same syntax as in
/etc/portage/package.use/qemu(-
alsa -
opengl
etc.)
Jocke
Yes, the inverted use.mask logic can be confusing if you are not
familiar with it. The
negative
flags
have a
special meaning within the context of of portage's incremental
stacking behavior, so they
can
still
be
useful, though not in the same way that you you attempted to use
them.
Just noticed that USE flags in profiles/package.use.mask override
everything so this
USE=thin emerge -av sys-fs/lvm2
will not turn on thin if thin is in profiles/package.use.mask
How can just change the default so a user can easily turn it on ?
Generally, setting the USE environment variable like that is poor
practice, because the setting will
not
persist the next time that you rebuild the package. So, you should set the
flag in
I know, this was just an example to illustrate that it did not work.
/etc/portage/package.use. You can unmask the flag for lvm2 like this:
echo sys-fs/lvm2 -thin /etc/portage/profile/package.use.mask
You misunderstand, I have sys-fs/lvm2 thin in
/etc/portage/profile/package.use.mask
and I want a user to able to override this setting, using USE=.. or
adding it
to their local /etc/portage/package.use file/dir
There's no other way to negate a use mask than to use
/etc/portage/profile/{use.mask,package.use.mask} as I
have described. I don't think that it makes much sense to negate a use mask
for a single emerge invocation.
If you want to do that, then why is the use flag masked anyway?
I am putting tougher a profile for my company where I want to specify default
USE flags for different apps/libs. Then a user who knows what he/she is doing
should be able to override these defaults. It is not possible as far
as I can tell to override negative USE flags or is there?
You can set default USE flags in the profile, and then the users can
override those settings locally (both positively and negatively). You
should not be using use.mask at all here. The profile can set
USE=-flag in make.defaults, or in packages.use, and the user can
override that without having to mess with use.mask.
--
Thanks,
Zac
Re: [gentoo-portage-dev] Portage and Update Security
On Tue, Mar 10, 2015 at 2:15 PM, Vladimir Diaz vladimir.v.d...@gmail.com wrote: Hi, I am a developer in the Secure Systems Lab at NYU. Our lab has collaborated with popular software update systems in the open-source community, including APT, yum, and YaST, to address security problems. More recently, we have been working on a flexible security framework co-developed with the Tor project that can be easily added to software updaters to transparently solve many of the known security flaws we have uncovered in software updaters. We would like to work with The Portage Development Project to better secure the Portage distribution system. I'm not familiar with your work on APT, do you have a link? TUF https://github.com/theupdateframework/tuf#a-framework-for-securing-software-update-systems (The Update Framework) is a library that can be added to an existing software update system and is designed to update files in a more secure manner. Many software updaters verify software updates with cryptographic signatures and hash functions, but they typically fail to protect against malicious attacks that target the metadata and update files presented to clients. A rollback attack is one such example, where an attacker tricks a client into installing older files than those the client has already seen (these older files may be vulnerable versions that have since been fixed). A full list of attacks and weaknesses the framework is designed to address is provided here https://github.com/theupdateframework/tuf/blob/develop/SECURITY.md#security . Our website http://theupdateframework.com/index.html includes more information about TUF, including: papers https://github.com/theupdateframework/tuf/tree/develop/docs/papers and a specification https://github.com/theupdateframework/tuf/blob/develop/docs/tuf-spec.txt. If you want to see how an existing project integrates TUF, there is a standards track proposal https://github.com/pypa/interoperability-peps/blob/master/pep-0458-tuf-online-keys.rst#abstract to the Python community that you can review. A more rigorous proposal that requires more administrative work on the repository, but provides more security protections, is also available https://www.python.org/dev/peps/pep-0480/. We were thinking of submitting a pull request that shows how such an integration would work. So there hopefully won't be much leg work on your end apart from deciding how the system should be configured (key storage, roles, etc.). Would a pull request be of interest? Is there anything you'd like us to say more about? I guess I am less concerned with adding support to portage (which as you note, is likely fairly straightforward) vs actually generating, publishing, and signing the metadata; which you would have convince the infrastructure team to do. Thanks, Vlad P.S. There are Informational http://wiki.gentoo.org/wiki/GLEP:57 and Standards Track http://wiki.gentoo.org/wiki/GLEP:58 GLEPs that reference our work and the security issues that our project addresses, but there hasn't been much recent activity on these proposals. FWIW, I would rather adopt the standard than continue with a gentoo specific thing; but I'm not the guy who is going to implement it. I would recommend talking to the GLEP author (robb...@gentoo.org) -A -- vladimir.v.d...@gmail.com PGP fingerprint = ACCF 9DCA 73B9 862F 93C5 6608 63F8 90AA 1D25 3935 --
Re: [gentoo-portage-dev] Re: running ebuild in src tree
On Thu, Mar 12, 2015 at 10:26 AM, Joakim Tjernlund
joakim.tjernl...@transmode.se wrote:
On Thu, 2015-03-12 at 01:27 +, Duncan wrote:
Zac Medico posted on Wed, 11 Mar 2015 12:03:10 -0700 as excerpted:
On 03/11/2015 11:56 AM, Joakim Tjernlund wrote:
On Wed, 2015-03-11 at 11:34 -0700, Zac Medico wrote:
On 03/11/2015 09:03 AM, Joakim Tjernlund wrote:
When developing code it would be really nice if one could run
your ebuild on that src tree as is(no
fetch, unpack etc.)
The existing convention is to create an ebuild with version
and use one of the live vcs eclasses
such as git-r3 to pull the live sources in the src_unpack
function. In a future EAPI, we plan to add
some features related to this [1].
I think you misunderstand, [1] is not what I want to do(I think):
Got my src working copy and made a few modds, not commitet yet. Now
I just want build/test etc. before
committing and to do that I just run
mytree/overlay/dev-util/myapp/myapp.ebuild compile and voila, my
code is built which I already have in mytree.
Well, you can create a - ebuild that copies your sources from
$directory to $WORKDIR. Maybe use an
environment to configure whether it pulls from a local directory or a
vcs repository.
@ Joakim T:
FWIW, a commonly recommended user-level portage optimization is to point
$PORTAGE_TMPDIR at a tmpfs mount. As long as you have sufficient memory,
that lets all building take place in the tmpfs and thus in memory,
eliminating many read-accesses and
most/all write accesses to permanent storage during the build and
(fake-)install phases.
In addition to speeding up emerge itself, this reduces build-time I/O,
which often becomes the bottleneck
on which other processes may be waiting as well, thus allowing other
processes more efficient access to
permanent storage while emerge is ongoing. Between this and setting
PORTAGE_NICENESS=20, emerge is /much/
better behaved during builds, interrupting other processes much less
and thus letting you carry on with
other things while emerge is doing its thing, with far less interruption.
=:^)
For instance, here I have /tmp as a tmpfs mount (with /var/tmp being a
bind-mount of the same tmpfs), and
in make.conf, have the line:
PORTAGE_TMPDIR=/tmp
Emerge then creates /tmp/portage, and within it, creates the usual cat/
pkg/ build trees, etc, as it
emerges various packages.
Obviously, your sources in permanent storage are going to be cache-copied
into memory as you do the build anyway, and pointing PORTAGE_TMPDIR at
tmpfs then becomes a copy to
(tmpfs) memory only. While that doesn't technically eliminate the
copies (since the read into tmpfs will
cache and you'll have the tmpfs copy as well), it DOES mean most of the
work beyond the initial read into
memory will be memory-only, so you DO eliminate the permanent-storage
copies.
Is that sufficiently close to what you were looking to do? Beyond that,
as Zac suggests, just have the ebuild grab the sources from wherever you
put them as your src_unpack, as at that point it'll be a copy to tmpfs,
and thus take essentially the same
time (or even less since it'll avoid the build-time writes to permanent
storage) as doing the in-place
build directly. Plus, creating a tmpfs mount if necessary, and
setting PORTAGE_TMPDIR, is easy, and
you'll dramatically speed-up normal builds as well. =:^)
No, there can be no copy of sources for what I want. It just gets in the
way having to do that.
Hacks like this seems to work:
I wouldn't really call it a hack either, but whichever ;)
post_src_compile() {
# make it compile every time
rm -f ${PORTAGE_BUILDDIR}/.compiled
}
post_src_install() {
# make it install every time
rm -f ${PORTAGE_BUILDDIR}/.installed
}
#hmm, doesn't seem to be an post_package function
#post_package() {
# rm -f ${PORTAGE_BUILDDIR}/.packaged
#}
src_unpack() {
#dir need to exist
mkdir -p ${S} || die
}
src_compile() {
EBUILDDIR=$(dirname ${FILESDIR})
MYTRUNK=${EBUILDDIR}/../../..
# add sandbox exceptions
addwrite ${MYTRUNK}
cd ${MYTRUNK} || die
cd ${PN}
.
}
I'm a bit curious what sort of workflow you are trying to achieve here is.
Which build artifacts are you looking for; the actual built binaries or the
built package that is merged into the livefs?
If the artifacts are packages, then I think this approach makes some
sense...but otherwise I'd just go into trunk and run the build process
(what does the ebuild gain you here?)
-A
Re: [gentoo-portage-dev] custom profiles?
On Fri, 2015-03-13 at 10:51 -0700, Zac Medico wrote: On 03/13/2015 05:08 AM, Joakim Tjernlund wrote: On Thu, 2015-03-12 at 17:51 -0700, Zac Medico wrote: On 03/12/2015 02:43 PM, Joakim Tjernlund wrote: Why is --dynamic-deps=y default? This feels like lying about your true deps, I am probably missing something here, an example would be great:) It's a legacy behavior, since portage has always behaved this way, and ebuild developers have relied upon it (resulting in broken dependency calculations without it). Here is odd difference: emerge --dynamic-deps=n changed-deps=y -a1 vanilla-sources ... Nothing to merge That's normal, because --changed-deps implies --selective (a number of options do this). If you add -- selective=n to the above command, you'll get the same result regardless of the --changed-deps option. I just did a sync and emerge -aNDu --dynamic-deps=n --changed-deps=y --selective=n world and again portage wanted to rebuild 150 pkgs. --selective=n seems to be the culprit, should I expect this from --selective=n ? Yes --selective=n is the opposite of --noreplace, so for the above command, it will rebuild everything in /var/lib/portage/world. hmm, this kind of a bummer --dynamic-deps=n implies --changed-deps=y which implies --selective=n and this makes the whole world to rebuild. Using just --dynamic-deps=n was not really safe if I understood corretly? Jocke
Re: [gentoo-portage-dev] custom profiles?
On Wed, 2015-03-11 at 13:43 -0700, Zac Medico wrote: On 03/11/2015 01:16 PM, Joakim Tjernlund wrote: On Wed, 2015-03-11 at 10:56 -0700, Zac Medico wrote: On 03/11/2015 08:48 AM, Joakim Tjernlund wrote: On Sun, 2015-03-08 at 11:58 -0700, Zac Medico wrote: On 03/08/2015 10:01 AM, Joakim Tjernlund wrote: On Sun, 2015-03-08 at 15:47 +, Joakim Tjernlund wrote: package.use/package.use.force is a bit different though: cat /etc/portage/package.use/qemu app-emulation/qemu vde -alsa -pulseaudio -bluetooth -opengl qemu_user_targets_x86_64 xattr virtfs static- user #Needed by static-user sys-libs/zlib static-libs dev-libs/glib static-libs sys-apps/attr static-libs Moving this to package.use/package.use.force does not respect -alsa, -pulseaudio, -opengl all flags which has a - on them, emerge wants to turn them on again. Am I missing something? Using portage 2.2.18 Appears one have to use package.use.mask for that. cat package.use.mask app-emulation/qemu alsa pulseaudio bluetooth opengl It would be handy if one could use the same syntax as in /etc/portage/package.use/qemu(-alsa - opengl etc.) Jocke Yes, the inverted use.mask logic can be confusing if you are not familiar with it. The negative flags have a special meaning within the context of of portage's incremental stacking behavior, so they can still be useful, though not in the same way that you you attempted to use them. Just noticed that USE flags in profiles/package.use.mask override everything so this USE=thin emerge -av sys-fs/lvm2 will not turn on thin if thin is in profiles/package.use.mask How can just change the default so a user can easily turn it on ? jcoke
Re: [gentoo-portage-dev] custom profiles?
On 03/14/2015 05:55 AM, Joakim Tjernlund wrote: On Fri, 2015-03-13 at 10:51 -0700, Zac Medico wrote: On 03/13/2015 05:08 AM, Joakim Tjernlund wrote: On Thu, 2015-03-12 at 17:51 -0700, Zac Medico wrote: On 03/12/2015 02:43 PM, Joakim Tjernlund wrote: Why is --dynamic-deps=y default? This feels like lying about your true deps, I am probably missing something here, an example would be great:) It's a legacy behavior, since portage has always behaved this way, and ebuild developers have relied upon it (resulting in broken dependency calculations without it). Here is odd difference: emerge --dynamic-deps=n changed-deps=y -a1 vanilla-sources ... Nothing to merge That's normal, because --changed-deps implies --selective (a number of options do this). If you add -- selective=n to the above command, you'll get the same result regardless of the --changed-deps option. I just did a sync and emerge -aNDu --dynamic-deps=n --changed-deps=y --selective=n world and again portage wanted to rebuild 150 pkgs. --selective=n seems to be the culprit, should I expect this from --selective=n ? Yes --selective=n is the opposite of --noreplace, so for the above command, it will rebuild everything in /var/lib/portage/world. hmm, this kind of a bummer I don't understand your motivation for using --selective=n with that command. Isn't the command useful without it? --dynamic-deps=n implies --changed-deps=y which implies --selective=n and this makes the whole world to rebuild. No, don't use --selective=n. I only mentioned it in order to explain the behavior that you observed. Using just --dynamic-deps=n was not really safe if I understood corretly? It's safe, but you may need --changed-deps in order for your dependency calculations to work (depends on how the dependencies of your installed packages have changed). -- Thanks, Zac
Re: [gentoo-portage-dev] custom profiles?
On 03/14/2015 09:12 AM, Joakim Tjernlund wrote: On Wed, 2015-03-11 at 13:43 -0700, Zac Medico wrote: On 03/11/2015 01:16 PM, Joakim Tjernlund wrote: On Wed, 2015-03-11 at 10:56 -0700, Zac Medico wrote: On 03/11/2015 08:48 AM, Joakim Tjernlund wrote: On Sun, 2015-03-08 at 11:58 -0700, Zac Medico wrote: On 03/08/2015 10:01 AM, Joakim Tjernlund wrote: On Sun, 2015-03-08 at 15:47 +, Joakim Tjernlund wrote: package.use/package.use.force is a bit different though: cat /etc/portage/package.use/qemu app-emulation/qemu vde -alsa -pulseaudio -bluetooth -opengl qemu_user_targets_x86_64 xattr virtfs static- user #Needed by static-user sys-libs/zlib static-libs dev-libs/glib static-libs sys-apps/attr static-libs Moving this to package.use/package.use.force does not respect -alsa, -pulseaudio, -opengl all flags which has a - on them, emerge wants to turn them on again. Am I missing something? Using portage 2.2.18 Appears one have to use package.use.mask for that. cat package.use.mask app-emulation/qemu alsa pulseaudio bluetooth opengl It would be handy if one could use the same syntax as in /etc/portage/package.use/qemu(-alsa - opengl etc.) Jocke Yes, the inverted use.mask logic can be confusing if you are not familiar with it. The negative flags have a special meaning within the context of of portage's incremental stacking behavior, so they can still be useful, though not in the same way that you you attempted to use them. Just noticed that USE flags in profiles/package.use.mask override everything so this USE=thin emerge -av sys-fs/lvm2 will not turn on thin if thin is in profiles/package.use.mask How can just change the default so a user can easily turn it on ? Generally, setting the USE environment variable like that is poor practice, because the setting will not persist the next time that you rebuild the package. So, you should set the flag in /etc/portage/package.use. You can unmask the flag for lvm2 like this: echo sys-fs/lvm2 -thin /etc/portage/profile/package.use.mask Or umask it globally like this: echo -thin /etc/portage/profile/use.mask -- Thanks, Zac
Re: [gentoo-portage-dev] custom profiles?
On Sat, 2015-03-14 at 10:58 -0700, Zac Medico wrote: On 03/14/2015 05:55 AM, Joakim Tjernlund wrote: On Fri, 2015-03-13 at 10:51 -0700, Zac Medico wrote: On 03/13/2015 05:08 AM, Joakim Tjernlund wrote: On Thu, 2015-03-12 at 17:51 -0700, Zac Medico wrote: On 03/12/2015 02:43 PM, Joakim Tjernlund wrote: Why is --dynamic-deps=y default? This feels like lying about your true deps, I am probably missing something here, an example would be great:) It's a legacy behavior, since portage has always behaved this way, and ebuild developers have relied upon it (resulting in broken dependency calculations without it). Here is odd difference: emerge --dynamic-deps=n changed-deps=y -a1 vanilla-sources ... Nothing to merge That's normal, because --changed-deps implies --selective (a number of options do this). If you add -- selective=n to the above command, you'll get the same result regardless of the --changed-deps option. I just did a sync and emerge -aNDu --dynamic-deps=n --changed-deps=y --selective=n world and again portage wanted to rebuild 150 pkgs. --selective=n seems to be the culprit, should I expect this from --selective=n ? Yes --selective=n is the opposite of --noreplace, so for the above command, it will rebuild everything in /var/lib/portage/world. hmm, this kind of a bummer I don't understand your motivation for using --selective=n with that command. Isn't the command useful without it? I have it my default emerge options --dynamic-deps=n implies --changed-deps=y which implies --selective=n and this makes the whole world to rebuild. No, don't use --selective=n. I only mentioned it in order to explain the behavior that you observed. Using just --dynamic-deps=n was not really safe if I understood corretly? It's safe, but you may need --changed-deps in order for your dependency calculations to work (depends on how the dependencies of your installed packages have changed). I am trying to find out what to put in emerge default options and this may need does relay compute in terms of default options. Does --dynamic-deps=n only work reliable with emerge -NDu world ? Jocke
Re: [gentoo-portage-dev] custom profiles?
On Sat, 2015-03-14 at 11:08 -0700, Zac Medico wrote: On 03/14/2015 09:12 AM, Joakim Tjernlund wrote: On Wed, 2015-03-11 at 13:43 -0700, Zac Medico wrote: On 03/11/2015 01:16 PM, Joakim Tjernlund wrote: On Wed, 2015-03-11 at 10:56 -0700, Zac Medico wrote: On 03/11/2015 08:48 AM, Joakim Tjernlund wrote: On Sun, 2015-03-08 at 11:58 -0700, Zac Medico wrote: On 03/08/2015 10:01 AM, Joakim Tjernlund wrote: On Sun, 2015-03-08 at 15:47 +, Joakim Tjernlund wrote: package.use/package.use.force is a bit different though: cat /etc/portage/package.use/qemu app-emulation/qemu vde -alsa -pulseaudio -bluetooth -opengl qemu_user_targets_x86_64 xattr virtfs static- user #Needed by static-user sys-libs/zlib static-libs dev-libs/glib static-libs sys-apps/attr static-libs Moving this to package.use/package.use.force does not respect -alsa, -pulseaudio, -opengl all flags which has a - on them, emerge wants to turn them on again. Am I missing something? Using portage 2.2.18 Appears one have to use package.use.mask for that. cat package.use.mask app-emulation/qemu alsa pulseaudio bluetooth opengl It would be handy if one could use the same syntax as in /etc/portage/package.use/qemu(-alsa - opengl etc.) Jocke Yes, the inverted use.mask logic can be confusing if you are not familiar with it. The negative flags have a special meaning within the context of of portage's incremental stacking behavior, so they can still be useful, though not in the same way that you you attempted to use them. Just noticed that USE flags in profiles/package.use.mask override everything so this USE=thin emerge -av sys-fs/lvm2 will not turn on thin if thin is in profiles/package.use.mask How can just change the default so a user can easily turn it on ? Generally, setting the USE environment variable like that is poor practice, because the setting will not persist the next time that you rebuild the package. So, you should set the flag in I know, this was just an example to illustrate that it did not work. /etc/portage/package.use. You can unmask the flag for lvm2 like this: echo sys-fs/lvm2 -thin /etc/portage/profile/package.use.mask You misunderstand, I have sys-fs/lvm2 thin in /etc/portage/profile/package.use.mask and I want a user to able to override this setting, using USE=.. or adding it to their local /etc/portage/package.use file/dir Or umask it globally like this: echo -thin /etc/portage/profile/use.mask
Re: [gentoo-portage-dev] custom profiles?
On 03/14/2015 11:35 AM, Joakim Tjernlund wrote: On Sat, 2015-03-14 at 10:58 -0700, Zac Medico wrote: On 03/14/2015 05:55 AM, Joakim Tjernlund wrote: On Fri, 2015-03-13 at 10:51 -0700, Zac Medico wrote: On 03/13/2015 05:08 AM, Joakim Tjernlund wrote: On Thu, 2015-03-12 at 17:51 -0700, Zac Medico wrote: On 03/12/2015 02:43 PM, Joakim Tjernlund wrote: Why is --dynamic-deps=y default? This feels like lying about your true deps, I am probably missing something here, an example would be great:) It's a legacy behavior, since portage has always behaved this way, and ebuild developers have relied upon it (resulting in broken dependency calculations without it). Here is odd difference: emerge --dynamic-deps=n changed-deps=y -a1 vanilla-sources ... Nothing to merge That's normal, because --changed-deps implies --selective (a number of options do this). If you add -- selective=n to the above command, you'll get the same result regardless of the --changed-deps option. I just did a sync and emerge -aNDu --dynamic-deps=n --changed-deps=y --selective=n world and again portage wanted to rebuild 150 pkgs. --selective=n seems to be the culprit, should I expect this from --selective=n ? Yes --selective=n is the opposite of --noreplace, so for the above command, it will rebuild everything in /var/lib/portage/world. hmm, this kind of a bummer I don't understand your motivation for using --selective=n with that command. Isn't the command useful without it? I have it my default emerge options --dynamic-deps=n implies --changed-deps=y which implies --selective=n and this makes the whole world to rebuild. No, don't use --selective=n. I only mentioned it in order to explain the behavior that you observed. Using just --dynamic-deps=n was not really safe if I understood corretly? It's safe, but you may need --changed-deps in order for your dependency calculations to work (depends on how the dependencies of your installed packages have changed). I am trying to find out what to put in emerge default options and this may need does relay compute in terms of default options. Right, options that imply --selective are not well suited for EMERGE_DEFAULT_OPTS unless you also put --selective=n in EMERGE_DEFAULT_OPTS, and then use --selective just for the commands that require it. As an alternative, we can add support for command-specific default options, as discussed here: https://bugs.gentoo.org/show_bug.cgi?id=540250#c1 Does --dynamic-deps=n only work reliable with emerge -NDu world ? No, it's well suited for EMERGE_DEFAULT_OPTS. It's just that you may find that you encounter dependency conflicts for some calculations unless you use --changed-deps. I use --changed-deps for all of my world updates. -- Thanks, Zac
