It might be worth skipping to 3.2, since that
> would simplify regex handling.
Stable isn't the measure. Stages are. Read the original email carefully
and you shall see why.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
x27;s an external program, it
can't die.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
established a long time ago
that FHS is considered silly and any compliance is merely because the
FHS people somehow managed to avoid screwing that particular area up.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Wed, 31 Dec 2008 17:21:45 +0100
Maciej Mrozowski wrote:
> On Wednesday 31 of December 2008 16:57:12 Ciaran McCreesh wrote:
> > Gentoo does not comply with the FHS. It was established a long time
> > ago that FHS is considered silly and any compliance is merely
> > b
st commonly used layout.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Thu, 1 Jan 2009 23:07:08 +0100
Maciej Mrozowski wrote:
> On Thursday 01 of January 2009 22:03:55 Ciaran McCreesh wrote:
> > No, FHS is not the most commonly used layout. The traditional Unix
> > layout is the most commonly used layout.
>
> So.. why not blindly use U
On Thu, 1 Jan 2009 23:28:52 +0100
Maciej Mrozowski wrote:
> On Thursday 01 of January 2009 23:15:20 Ciaran McCreesh wrote:
> > On Thu, 1 Jan 2009 23:07:08 +0100
> > > So.. why not blindly use Unix layout everywhere instead (for
> > > Gentoo news as well)
>
> &
ckage
manager aware of packages in overlays that it doesn't have configured.
Shouldn't have to fire up a web browser just to get basic information
on a third party package...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Sun, 4 Jan 2009 22:18:38 +0530
"Nirbheek Chauhan" wrote:
> On Sun, Jan 4, 2009 at 9:38 PM, Ciaran McCreesh
> wrote:
> > On Sun, 4 Jan 2009 21:34:18 +0530
> > "Nirbheek Chauhan" wrote:
> >> How about this:
> >
> > It's utterly us
tical experience showed
them being very widely used, but they're just that -- shortcuts for
widely used cases.
This lot should probably be in the new developer quiz, if anyone's
maintaining it these days.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
foo? ( cat/pkg[-bar] ) !foo? ( cat/pkg[bar] )
> cat/pkg[!foo=]
>
> IMO, this is simple enough to understand, and use :)
It's utterly useless. Unlike the existing shortcut forms, what you're
after isn't widely enough used to warrant its own shortcut. Use the
exp
On Sat, 10 Jan 2009 18:03:17 -0600
Ryan Hill wrote:
> I'm really hoping this isn't a stable candidate. :P
Is an earlier gcc 4.3 a stable candidate, or have those plans been
abandoned?
(I'm wondering whether it's worth the pain of dealing with 4.1's lack
of tr1 r
specifying dependencies for
use of ROOT properly in the future -- it'd just be new labels, not
zillions of new variables.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
d, run time, post, install, test or use
* however many userland ABIs there are
* however many Python ABIs there are
It quickly becomes clear that various things that are wanted in the
future can't be done by having lots of variables.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
messy with eclasses even if developers did know that += is a 3.1
feature...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
If they are, at the very least we'd
need a guarantee from the Portage people that they're not going to
change its behaviour yet again, and ideally they'd revert the recent
behaviour changes back to what stable Portage does.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
eration. Which means it won't work for overlays.
> Then we could add a repoman check for new features, if we wanted.
Can't do that unless you write a feature-complete bash parser and
pretend-execute every possible path an ebuild can take...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Thu, Jan 22, 2009 at 5:02 PM, Ciaran McCreesh
wrote:
> Only if you're guaranteed bash 3.1 on boxes that do metadata
> generation. Which means it won't work for overlays.
Come to think of it... This is yet another reason GLEP 55 is necessary.
--
Ciaran McCreesh
> foo.ebuild, etc.
That still wouldn't catch a lot of things... Unfortunately repoman
can't replace developer knowledge.
Short of persuading upstream to add a feature that makes bash able to
die if it detects you using features added in a version newer than the
one you tell it,
r EAPIs then too. Did you see
that discussion?
As far as PMS is concerned, you just need to create a file named 'eapi'
containing a single line with '1' in it in each profiles/ directory in
which you want to use slot deps.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
les don't make sense. Any clever use case you think
you have for them doesn't work and needs proper dedicated handling.
Slot deps, of course, do make sense.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
number
of packages in each category. Purely from a performance perspective, a
few small categories doesn't hurt much; very large categories are a
much bigger problem.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
tree [1].
Are these people really all going to remember to run some command at
the top level of the repository before every commit, and to git add the
relevant files for everything (thus making really messy commits)?
Sticking metadata cache files under version control really is a perfect
e
l that generates a tarball, including metadata, for a
repo, and have people run that on a cron and distribute it via http?
That's just as easy to host, and anyone running an overlay big enough
to make this impractical already has the resources to deal with rsync
instead...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
s create an unnecessary burden. I think that
> it adds a significant level of convenience to be able to use a
> version control system as a single distribution channel.
Which is offset and more by the massive inconvenience of having to
keep track of and store junk under version control.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
hink we have a justifiable exception to the rule.
If you start encouraging this approach, are you prepared to make
Portage warn extremely noisily if a repository-provided (as opposed to
user generated) cache entry is found to be stale?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
do you trust overlay maintainers?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Mon, 09 Feb 2009 16:15:55 +0200
Petteri Räty wrote:
> > How much do you trust overlay maintainers?
>
> It shouldn't be that hard to sandbox the overlays for cache
> generation.
Uh. Really? I'd be interested to see how you plan to pull that one off.
--
Ciaran
t merges master to master-with-metadata, and as part
of the merge commit, generates all necessary metadata for the range
it's merging.
* Store either the partial hash or the owning repository and timestamp
of each eclass used by an ebuild in its metadata.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
is equal to or
ahead of the most recent 0.34.x release), a 0.36 branch (which is equal
to or ahead of the most recent 0.36.x release) and a master branch
(which is ahead of any release) using the live property?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Fri, 13 Feb 2009 23:17:03 +0100
Luca Barbato wrote:
> Ciaran McCreesh wrote:
> > No, but something can represent the most commonly used models. We
> > can't do -scm packages for upstreams that do utterly crazy stuff
> > anyway, so we'll stick to the reasonably s
handling.
> Then if you continued to read you'll notice that
...you got so incoherent I gave up trying to work out what you're on
about. You still haven't shown how to solve the simple example I gave
earlier in the thread.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
eply isn't exactly polite
> or mature.
No. Really. Again. You've been steadily talking nonsense on this whole
issue. Please step back, start again and clearly and concisely explain
in coherent English how you solve the simple example I gave earlier in
the thread. I am far from
cache entry.
Validate it against what? If EAPI is unsupported, the package
manager can't make use of INHERITED to see what DIGESTS means.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
sting? Strikes me as excessive, especially since it
only works for EAPIs where the scope of changes is small enough to
keep the meaning of INHERITED and DIGESTS the same...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
se straight away with rules for "don't know how to use this
EAPI, but do know how to read metadata cache entries for it" whilst
keeping new EAPI support for the next major release.
Honestly, I don't think it'll be useful often enough that it's worth
the added ick.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
sn't hit a parse error
> first).
You just need to give your package manager a way of dealing with EAPIs
where it can verify that DIGESTS is correct, but not make use of the
ebuild in question beyond that. Rather than having supported and
unsupported EAPIs, have supported, partially-understood and unsupported
EAPIs.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
e care of it (working patches exist, anyone?).
*cough* fixed in eclectic *cough*
Unfortunately Cardoe hasn't followed through on his plans to move
Gentoo over...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
n some arbitrary manner is the wrong solution.
This was already discussed at length prior to the Council reaching
their decision.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
#x27;t do anything.
And if you're trying to make a space-critical distribution, start
looking at the big things, not the 4% things.
Easy.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ig things, not the 4% things.
>
> Typical documentation consists of text files, so I would expect to
> save of the order of 50 % by compressing them. How did you obtain
> above number of 4 %?
The proportion of ebuild-managed content in /usr/share/doc (with
USE=doc, so it's a m
t in such a way that it works automatically for all ebuilds,
without any developer intervention (but providing some way for ebuilds
to disable it where necessary).
--
Ciaran McCreesh
signature.asc
Description: PGP signature
others... that doesn't mean I do like wasting space on
> something not space critical when compression algorithms exist.
If you care about space, focus on something relevant. You are wondering
whether turning the radio off will make your car more fuel efficient
whilst driving with flat
start:
> http://archives.gentoo.org/gentoo-dev/msg_eb1f7952eb2f0fe725bde331a4d9ae30.xml
Can you demonstrate that it's even remotely useful?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Wed, 18 Feb 2009 14:01:44 -0500
Michael Sterrett wrote:
> It's already fixed.
And have you learned not to try such blatantly irresponsible and
childish behaviour on a tree used by other people?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ou this if you run --info without a spec:
> No packages were specified on the command line, so detailed
> information is not available (Paludis can display detailed information
> for both installed and installable packages).
Please try harder next time.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Thu, 19 Feb 2009 00:03:24 +0100
Jeroen Roovers wrote:
> On Wed, 18 Feb 2009 22:55:06 +
> Ciaran McCreesh wrote:
> > ...which is why you ask for 'paludis --info pkg', not 'paludis
> > --info'.
>
> Spread the word!
http://git.pioto.org/gitweb/pa
ut ebuild phases being executed(like ">>> Starting
> builtin_initmisc" etc...) ?
That's there in case something goes wrong. If you unexpectedly get a
"rm blah: permission denied" or whatever, it's helpful if you know
*why* something's being removed.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
delete things from the inclusion
list. And since reliably rewriting links in HTML when compressing is at
best tricky and at worst impossible (think JavaScript navigationy
things), is there ever going to be any need for removing from the
exclusion list?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
under their feet.
No it doesn't. It's transparent to users using an older package manager.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
s disliked by enough people to lead
> the situation to be discussed in the council.
There's no surprise at all. It's extremely clear.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
;t particularly care if it were
> implemented- although I'd rather see it go in a seperate repo along
> w/ the dozen other fixups needed, preferably starting w/ overlays...
Well yes, but that's never realistically going to happen. 55's one of
the few repository format fixe
't work with existing packages or existing package managers.
> Sure, if you make some major change analogous to switching from
> the .rpm to the .deb package format then maybe an extension change
> would make sense. But, why expose the inner workings of the package
> file format to the filesystem?
For the same reason versions and package names are already in the
filename.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
gt; time the eapi is changed. This is slightly against the principle
> >> of the least surprise and apparently is disliked by enough people
> >> to lead the situation to be discussed in the council.
> >
> > There's no surprise at all. It's extremely clear.
>
> Not that much.
How is '.ebuild-3' being used to specify version 3 of the ebuild format
in the least bit surprising?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
; in the per-pkg eclass and
EAPI="3" in the global one instead...
And whilst this is clearly a deliberate example of how to create
craziness, the only difference between this and the real world is that
the craziness is obvious here. The current rules really are this
complicated, and we can't retroactively fix them.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ively enforce a new rule
requiring it to be specified in a particular way right after the header
(which is bad, since it breaks things people have already done), it
*still* doesn't let us change global scope behaviour since current
package managers don't extract EAPI the horrid way.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ly going back and saying "oh, we have to
wait another year or more again" is unacceptable.
> > In foo.eclass:
> >
> > EAPI="3"
>
> I thought this was prohibited.
It's legal, and people have done it, but it's considered by most people
to be a horrible QA violation.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
again" is unacceptable.
>
> Had we found a compromise at the beginning of glep55, that extra year
> would be over by now...
And we'd be starting on the next batch of "oh, we need to wait another
year". Had GLEP 55's necessity been accepted a year ago, we'd h
repositories that
follow Gentoo's QA rules. It's in the same category as rules about
what indenting style to use, not rules about how variables are
formatted.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
versionator with a package manager internal. The complexity for both of
those is in the upgrade path, not the implementation.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
> -
> > EAPI=5
> > inherit myeclass
>
> Invalid
QA violation, but legal and a pain in the ass.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
nd the spec doesn't forbid it.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Mon, 23 Feb 2009 18:47:07 -0500
Richard Freeman wrote:
> It seems like we could be up to ebuild-kde4-3.2 in six months.
Why on earth do people think that? Of all the crazy being thrown
around, this is the only one wearing a tutu.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
xisting package managers, and it
doesn't let you change name or version rules.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
change name or
versioning rules.
Again, these are all things that have been discussed at length
previously. Please either come up with a legitimate technical
objection, or admit that you've seen the light.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
nges to be done safely (although
not carelessly...).
--
Ciaran McCreesh
signature.asc
Description: PGP signature
d
> the need to do so could be handled via future GLEPs.
Developers already have to stop and think and consult the conveniently
available table of features for EAPIs. By splitting the EAPI concept in
two you're doubling the amount of data to be learnt.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Tue, 24 Feb 2009 17:04:28 +0100
Luca Barbato wrote:
> Ciaran McCreesh wrote:
> > On Tue, 24 Feb 2009 08:08:23 +0100
> > Uh, your benchmarks are nonsense.
>
> Provide your nonsensical ones.
You're doubling the number of files that have to be read for an
operatio
27;s design, so much so that I will likely join
> the ranks of those who abandon it, not only as a dev, but also as a
> user.
"If you paint the bikeshed, I shall throw my toys out of the pram and
run off crying.".
Why don't you propose a viable alternative instead of making threats?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
7;t be able to change the version rules, and we would be
suffering a substantial performance hit.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
't
be in the filename...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
less of an impact. There's no
need to compromise here.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ed for
> uniqueness
So why's PN in there then?
> 2) it makes sense to have these in the filename, but not
> internal meta-data
For those of us who understand the process, it makes sense to have EAPI
in the filename too.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Tue, 24 Feb 2009 21:59:39 +0530
Nirbheek Chauhan wrote:
> On Tue, Feb 24, 2009 at 9:26 PM, Ciaran McCreesh
> wrote:
> > ...and it means we can't change name or version rules.
>
> And has such a case come to light recently where it was *essential* to
> do so? Why
a viable alternative instead of making
> > threats?
>
> Not a threat. And this will be my last post on the topic. I will not
> take your bate and continue to argue, creating more noise on this
> list - I've expressed how I feel.
This isn't about how you feel.
On Tue, 24 Feb 2009 08:42:44 -0800
Alec Warner wrote:
> On Tue, Feb 24, 2009 at 8:37 AM, Ciaran McCreesh
> wrote:
> > On Tue, 24 Feb 2009 08:33:19 -0800
> > Alec Warner wrote:
> >> Hey I never said its a perfect solution; but I'm a fan of the 'it
> &g
learnt.
>
> I would think that this is a very small cost, and the benefit would be
> (I hope) that more people would agree on the solution and then we can
> go forward. Is that not a valid consideration?
I'd expect to see changes that would warrant a major bump in every
other EAPI or so anyway, so it's not really worth the complexity.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
> >>> Again, these are all things that have been discussed at length
> >>> previously. Please either come up with a legitimate technical
> >>> objection, or admit that you've seen the light.
> >> the glep doesn't show any of those nor reference to it, as I said
> >> before, do your homework and probably more people will be happier
> >> with your proposals.
> >
> > Why should it? The C++ standard doesn't explain why you should use
> > it instead of Java...
>
> In fact many people do wonderful things with java and many more just
> do over engineered mess with C++?
Your trolling is going rapidly downhill.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
omes from
the great Satan and all his little minions... If you're going to throw
an equivalent but supposedly compromising solution at people, go for
'.eapi3.eb' instead.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Tue, 24 Feb 2009 20:28:43 +0100
Alexis Ballier wrote:
> On Tue, 24 Feb 2009 18:24:16 +
> Ciaran McCreesh wrote:
> > On Tue, 24 Feb 2009 18:16:54 +0100
> > Luca Barbato wrote:
> > > > You're doubling the number of files that have to be read for an
>
On Tue, 24 Feb 2009 15:07:29 -0500
Jim Ramsay wrote:
> Ciaran McCreesh wrote:
> > People are struggling with the one level scheme we have now. We're
> > already having to produce fancy tables and summaries for new EAPIs
> > because people can't keep track o
e, or whatever. Just how much more flexibility
> than that is needed?
I remember hearing that years ago, except it was "well you can't change
global scope behaviour for EAPIs, but just how much more flexibility
than that is needed?".
--
Ciaran McCreesh
signature.asc
Description: PGP signature
p up
with the two or three EAPIs they'll ever be working with on a regular
basis, but they probably can't keep up with that if you double it.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
e.g. the MSDOS Partition Table, the Extended Partition, the High
> Memory Area.
Except that once we have EAPI in the file extension, we can change
anything we want in arbitrary ways without having to worry about
backwards compatibility, so we won't need silly hacks.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
u know what
the EAPI is.
> You:
> - have to open them on regen, no matter what (you are adding it to
> portage)
> - the cache entry has already the eapi value so there it is.
Can't use the cache until you know what the EAPI is.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
xtension.
All we have to do is use a new EAPI value, and then we can change
whatever we like because non-supporting package managers will ignore it.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Tue, 24 Feb 2009 23:48:27 +0100
Luca Barbato wrote:
> Ciaran McCreesh wrote:
> > Not true. You don't know whether the cache is valid until you know
> > what the EAPI is.
>
> If you are on the user scenario the cache is valid.
Uh. Wrong.
> > Can't use t
the current cache-format for the current *.ebuild and
> another for *.ebuild-N (where I mean by cache-format the contents of
> the cache-files)?
If you have GLEP 55 you don't need it.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
only drawback is when you open a file, see there that you
> can't handle the eapi, then close it and open an older one.
Uh. No. The drawback is that you're opening around ten thousand files
that would otherwise not be opened. That's a huge cost.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
;
> portage will warn about not knowing pkg-version_foo and will ignore
> it.
Yes, it will warn noisily. This is unacceptable, since stable users
will have months and months of noise when new rules come along.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
to see"...
No, as in it'll result in zillions of users wondering what's going on
and why their screen is getting spammed, and zillions of bug reports and
forum posts.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Wed, 25 Feb 2009 17:17:29 +0100
Luca Barbato wrote:
> I'd rather see more people backing their ideas with numbers...
I already told you your numbers are nonsense.
Of course opening the file when you've already opened it isn't going to
make any difference.
--
Ciaran McCree
ger upgrade
> which would also have the eapi function).
Unportable, and still leaks out to users.
This whole thing only looks neat until you think about it...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
example doesn't give the user
> any indication that they're not seeing ebuilds due to EAPI (in other
> words loss of functionality that exists now).
Given you're a proponent of not showing users things that're merely
masked...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
of not showing users things that're merely
> > masked...
>
> Say what you want; g55 still has the flaw.
Any sane package manager can, immediately upon a new EAPI being
defined, do a stable release updated with minimal information about the
new EAPI to enable it to show up as being there but not supported, even
if full support needs a new major version and lots of ~arch testing
time.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Wed, 25 Feb 2009 23:43:44 -0100
"Jorge Manuel B. S. Vicetto" wrote:
> Ciaran McCreesh wrote:
> > On Wed, 25 Feb 2009 16:02:46 -0800
> > Brian Harring wrote:
> < snip a few arguments>
>
> Ciaran and Brian,
>
> please respect Pettery's requ
ible. So if you must go with
something other than GLEP 55, along with all the restrictions and mess
that doing so imposes, this is the one to pick...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Thu, 26 Feb 2009 18:07:32 +
Ciaran McCreesh wrote:
> There's a less extreme variant on this that's slightly cleaner, and
> with appropriate weaseling is also less messy. Simply add the
> following very carefully worded additional requirement for future
> EAPIs, and r
g are legal:
EAPI=$(echo 1 )
EAPI=${PV}
EAPI=$( a=() ; a+=3 ; echo ${a[0]} )
--
Ciaran McCreesh
signature.asc
Description: PGP signature
our
> wonderful new secretary could do something along the lines of the
> above doc?
Anyone but Luca please. Luca's been busy selectively ignoring problems
with his proposal, refusing to answer objections to it and claiming it
solves problems that it doesn't.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
801 - 900 of 3510 matches
Mail list logo
