Re: [gentoo-dev] CWD-relative ROOT support in portage: misfeature?
On 2012-08-17, at 11:00 PM, "Gregory M. Turner" wrote:
> It has come to my attention that gentoo supports "relative" ROOT, which is to
> say that, by design, portage will act as though (in bash terms):
>
> ROOT
>
> equals
>
> "${PWD}/${ROOT}"
>
> when (again in bash terms):
>
> [[ $ROOT != /* ]]
>
> at the moment execution crosses the boundary between a non-portage program
> and a portage program. For example, I ran the following from a bash-prompt
> with PWD=/tmp in a portage-2.2 ~amd64 environment:
>
> greg@fedora64vmw /tmp $ mkdir foo
> greg@fedora64vmw /tmp $ ROOT=foo portageq envvar ROOT
> /tmp/foo/
>
> Question: do we really want this behavior?
>
> I have reason to believe that almost nobody uses this feature (namely,
> gcc-config and binutils-config are both broken under it for ages and nobody
> filed a bug or fixed it: see bugzilla #431104).
>
> Does /anybody/ use this feature? If not, I'd suggest that the portage team
> might ask itself whether the benefits of continuing to maintain it are
> greater than the hassle and potential for error it facilitates.
>
> Just my 2c,
>
> -gmt
Sorry for the HTML response... am on the road.
I don't use the feature but I would fully expect said behavior. ie, going with
the example above I would expect that I'd need the / in front for the path to
not be relative.
>
Re: [gentoo-dev] Re: Questions about SystemD and OpenRC
On 8/16/2012 6:26 PM, Rich Freeman wrote:
On Thu, Aug 16, 2012 at 4:05 PM, Michael Mol wrote:
The limited-visibility build feature discussed a week or so ago would
go a long way in detecting unexpressed build dependencies.
[snip]
If portage has the
dependency tree in RAM then you just need to dump all the edb listings
for those packages plus @system and feed those into sandbox.
That just requires reading a bunch of text files and no searching, so it
should be pretty quick.
Portage could hypothetically compile such a list while it crawls the
package dependency tree, but I suspect the cost will not be small as you
predict.
As far as I can tell the relevant calls to
check for read access are already being made in sandbox already, and
obviously they aren't taking forever. We just have to see if the
search gets slow if the access list has tens of thousands of entries
(if it does, that is just a simple matter of optimization, but being
in-RAM I can't see how tens of thousands of entries is going to slow
down a modern CPU even if it is just an unsorted list).
I appreciate your optimism but I think you're underestimating the cost.
Can't speak for others, but my portage db's churn too much for comfort
as is. Once we start multiplying per-package-dependency iteration by
the files-per-package iteration, that's going to be O(a-shit-load).
Of course, where there's a will there's a way. I'd be surprised if some
kind of delayed-evaluation + caching scheme wouldn't suffice, or,
barring that, perhaps it's time to create an indexed-database-based
drop-in replacement for the current portage db code.
I've enclosed some scripts you may find helpful in looking at the
numbers. They are kind-of kludgey (originally intended for
in-house-only use and modified for present purposes) but may help shed
some light, if they aren't too buggy, that is...
"dumpworld" slices and dices "emerge -ep" output to provide a list of
atoms in the complete dependency tree of a given list of atoms (add
'@system' to get the complete tree, dumpworld won't do so).
"dumpfiles" operates only on packages installed in the local system
(non-installed atoms are silently dropped), and requires/assumes that
'emerge -ep world' would not change anything if it is to give accurate
information. It takes a list of atoms, transforms them into the
complete lists of atoms in their dependency tree via dumpworld, merges
the lists together, and finds the number of files associated with each
atom in portage. Any collisions will be counted twice, since it doesn't
keep track. It also doesn't add '@system' unless you do. By default it
emits:
o A list of package atoms and the files owned by each atom (stderr)
o total atoms and files
o average filename length
What is, perhaps, more discouraging than the numbers it reports is how
long it takes to run (note: although I suspect an optimized python
implementation could be made to do this faster by a moderate constant
factor, I'm not sure if the big-oh performance characteristics can be
significantly improved without database structure changes like the ones
mentioned above).
My disturbingly bloated and slow workstation gives these answers (note:
here it's even slower because it's running in an emulator):
greg@fedora64vmw ~ $ time bash -c 'dumpfiles @system 2>/dev/null'
TOTAL: 402967 files (in 816 ebuilds, average path length: 66)
real15m33.719s
user13m18.909s
sys 2m8.436s
greg@fedora64vmw ~ $ time bash -c 'dumpfiles chromium 2>/dev/null'
TOTAL: 401300 files (in 807 ebuilds, average path length: 66)
real15m28.900s
user13m15.126s
sys 2m8.088s
My workstation is surely an "outlier" as I have a lot of dependencies
and files due to multilib, split-debug, and USE+=$( a lot ). It's also
got slow hardware Raid6 and the emulator only gives it 2G of ram to work
with. But I'm a real portage user; I'm sure there's other ones out
there, if not many, with similar constraints.
-gmt
#!/bin/bash
if [[ x$(qlist -IC app-portage/portage-utils)x == xx || \
x$(qlist -IC app-portage/gentoolkit)x == xx ]] ; then
echo "This utility requires both app-portage/portage-utils" >&2
echo "and app-portage/gentoolkit. Emerge them both and try again." >&2
exit 1
fi
declare -a arguments atoms
arguments=( )
atoms=( )
verbose=yes
redic=no
for arg in "$@" ; do
case $arg in
-q|--quiet) verbose=no ;;
-r|--redic) redic=yes ;;
*) arguments=( "${arguments[@]}" "$arg" ) ;;
esac
done
[[ ${#arguments[*]} == 0 ]] && arguments=( '@world' )
for arg in "${arguments[@]}" ; do
if [[ ${arg} == @* ]] ; then
newatoms=( "${arg}" )
else
newatoms=( "$( qlist -eICv "${arg}" | sed 's/^/=/' )" )
fi
newatoms=( $( dumpworld "${newatoms[@]}" ) )
result=$?
[[ ${result} != 0 ]] && { echo "dumpworld failed, giving
Re: [gentoo-dev] glibc-2.16 moving to ~arch
On Sat, 18 Aug 2012 12:00:17 -0400 Mike Frysinger wrote: > *yawn* such a drama queen. > > i never said "i am going to do this everyone else be damned". i did > say "i will probably do this soon". but that is why i posted to > gentoo-dev in the first place -- to get feedback from others. > > gnutls breakage: not relevant. you're causing that breakage by not > adding a simple patch that most every other package has merged. > conflating the issue to a major ABI bump is also irrelevant. > > boost breakage: if 1.50 is going to be unmasked soon, i can wait for > that. > > general breakage: we can't sit around waiting for all packages to get > fixed. if people aren't going to fix packages after being given > notice, then they get tree cleaned. not a big deal. > -mike You both (Mike and Diego) make good and valid points regarding the unmasking of glibc-2.16 and its impact on other packages (and, subsequently, users). However, the personal attacks against one another add nothing to the discussion. Resorting to ad hominem relegates the discourse to a less-than-helpful state for everyone involved. Please try to focus on the points raised by other developers and users, so that the end result is something that benefits the community and distribution as a whole. Cheers, Nathan Zachary
Re: [gentoo-dev] glibc-2.16 moving to ~arch
*yawn* such a drama queen. i never said "i am going to do this everyone else be damned". i did say "i will probably do this soon". but that is why i posted to gentoo-dev in the first place -- to get feedback from others. gnutls breakage: not relevant. you're causing that breakage by not adding a simple patch that most every other package has merged. conflating the issue to a major ABI bump is also irrelevant. boost breakage: if 1.50 is going to be unmasked soon, i can wait for that. general breakage: we can't sit around waiting for all packages to get fixed. if people aren't going to fix packages after being given notice, then they get tree cleaned. not a big deal. -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: glibc-2.16 moving to ~arch
On 18/08/12 18:42, Mike Frysinger wrote: On Saturday 18 August 2012 02:01:12 Diego Elio Pettenò wrote: On Fri, Aug 17, 2012 at 10:44 PM, Mike Frysinger wrote: there's a trivial patch needed to make 1.49 work. forcing people to use 1.50 is purely the boost's maintainers choice. [...] there's a trivial patch long been available that you've refused to merge. so any errors here are of your choosing. So you pretend that people apply "trivial patches" because you're in a hurry to unmask something yes, the patch here is trivial. it removes 1 line of unused code and has fixed a lot of other packages. deflecting the argument to a flawed system of your own creation doesn't change it. if you're worried about gnutls breakage, you've only yourself to blame. -mike Maybe Diego loaded the gun, but you're the one pulling the trigger. In any event, the user is the one getting shot, not you nor Diego.
Re: [gentoo-dev] glibc-2.16 moving to ~arch
On Sat, Aug 18, 2012 at 8:42 AM, Mike Frysinger wrote: > yes, the patch here is trivial. it removes 1 line of unused code and has > fixed > a lot of other packages. deflecting the argument to a flawed system of your > own > creation doesn't change it. if you're worried about gnutls breakage, you've > only yourself to blame. I'm worried that one developer thinks that he can make a change to _the_ base library for the tree over a weekend, without informing anybody else of his plan if not one day before. I'm worried that Gentoo's health depends on the whim of a person who can't see the needs of others and only care about his own. So unless you're so full of yourself that you still think it's okay for you to do this by announcing it the day before, start actually working _with_ others instead than _against_ other: fix your crap that is blocking glibc 2.16, and see how soon the others can fix theirs. If you can't do that, then I'd suggest you step down and take a vacation, because you're totally out of your mind.
Re: [gentoo-dev] [PATCH eutils 1/2] Add dointo && newinto.
On Saturday 18 August 2012 03:21:20 Michał Górny wrote:
> On Fri, 17 Aug 2012 23:25:10 -0400 Mike Frysinger wrote:
> > On Thursday 16 August 2012 16:19:44 Michał Górny wrote:
> > > --- a/eutils.eclass
> > > +++ b/eutils.eclass
> > >
> > > +# Install all specified s into . This doesn't
> > > modify global +# 'insinto' path. Alike doins, calls 'die' on
> > > failure in EAPI 4+; in earlier +# EAPIs, returns false in that case.
> >
> > i don't really see the point in differentiating here. we have plenty
> > of helpers that have always implicitly called die regardless of the
> > EAPI level, and it's not like you'd be breaking any existing behavior
> > since no one is using this already. and even then, you'd be
> > "breaking" builds that were already broken.
>
> Maybe. Alternatively, I could end up doing doins || die || die. It will
> work but what's the point?
the double die only kicks in with EAPI=4+, and even then is hidden to most
people at the code level. it also looks a lot better than:
(
insinto ... && doins ...
)
case ${EAPI:-0} in 0|1|2|3) [[ $? -ne 0 ]] && die ;; esac
vs
(insinto ... && doins ...) || die
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] glibc-2.16 moving to ~arch
On Saturday 18 August 2012 02:01:12 Diego Elio Pettenò wrote: > On Fri, Aug 17, 2012 at 10:44 PM, Mike Frysinger wrote: > > there's a trivial patch needed to make 1.49 work. forcing people to use > > 1.50 is purely the boost's maintainers choice. > > [...] > > > there's a trivial patch long been available that you've refused to merge. > > so any errors here are of your choosing. > > So you pretend that people apply "trivial patches" because you're in a > hurry to unmask something yes, the patch here is trivial. it removes 1 line of unused code and has fixed a lot of other packages. deflecting the argument to a flawed system of your own creation doesn't change it. if you're worried about gnutls breakage, you've only yourself to blame. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH eutils 1/2] Add dointo && newinto.
On Fri, 17 Aug 2012 23:25:10 -0400
Mike Frysinger wrote:
> On Thursday 16 August 2012 16:19:44 Michał Górny wrote:
> > --- a/eutils.eclass
> > +++ b/eutils.eclass
> >
> > +# Install all specified s into . This doesn't
> > modify global +# 'insinto' path. Alike doins, calls 'die' on
> > failure in EAPI 4+; in earlier +# EAPIs, returns false in that case.
>
> i don't really see the point in differentiating here. we have plenty
> of helpers that have always implicitly called die regardless of the
> EAPI level, and it's not like you'd be breaking any existing behavior
> since no one is using this already. and even then, you'd be
> "breaking" builds that were already broken.
Maybe. Alternatively, I could end up doing doins || die || die. It will
work but what's the point?
> > +dointo() {
> > + [[ ${#} -gt 2 ]] || die 'Synopsis: dointo
> > [...]'
>
> "Usage" is the standard prefix, not "Synopsis"
Fixed.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
