Nor do most Unix apps, since they tend to be written in C using all
those C library functions that work on null terminated strings.
Null introduces far more problems than it solves, character-wise...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
not attempt to write on both sides of the paper at once.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
;t solve this, they can't
install Gnome off a stage 3...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
makes the tree unusable.
> Really, it seems to be an additional type of dependency that neither
> DEPEND or RDEPEND fully describe, and this DEPEND+RDEPEND idea isn't
> quite capturing it either.
Yup, and for future EAPIs labels can fix this. But we have to have a
sound solution f
point is, one of the two wordings in the original email is enough.
In fact, both are, but they have different implications, and selecting
the right one is important.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ild phase
> they are necessary for?
Not with current EAPIs we can't.
> SRC_UNPACK_DEP="app-arch/unzip"
> SRC_COMPILE_DEP="dev-scheme/bigloo"
> SRC_INSTALL_DEP=""
Labels are a cleaner solution to this. But again, we're discussing
current EAPIs here.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
about one specific issue regarding how we word things for
current implementations. The two wordings in the original email do not
have equivalent implications, and selecting the correct one affects
whether certain problems are solvable. Let's discuss that, not what
we're going to do
at/b-2
cat/b-1 is installed and has RDEPEND cat/a
cat/b-2 is to be installed and has DEPEND cat/a and RDEPEND =cat/a-2
Solve this and enlightenment shall be yours!
Or a headache.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
gt; as I proposed AIUI, i.e. finer-grained deps.
Labels do that and a lot more, and without the explosion in number of
metadata keys. But they're a different discussion.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Mon, 21 Apr 2008 12:10:53 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> >> Really, it seems to be an additional type of dependency that
> >> neither DEPEND or RDEPEND fully describe, and this DEPEND+RDEPEND
> >> idea isn't qui
real way that I could see this
> working is if we tracked what was installed as an optional dependency,
> and not reinstall it if it has been removed the next time the
> depending package is merged.
Sort of like what kdebuild has for suggested dependencies, but less
strong?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
x27;m not going to give examples, because that'll just
degenerate into "oh, so we can change this one particular case to do
$blah", whilst missing the bigger point). Of everything suggested, only
the two original wordings are correct, and of those two, the second is
better defined.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Mon, 28 Apr 2008 05:57:04 +0100
Steve Long <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > On Sun, 27 Apr 2008 10:41:57 +0100
> > Steve Long <[EMAIL PROTECTED]> wrote:
> >> Use PDEPEND.
> >
> > PDEPEND has a different meaning,
do a partial rebuild for the addition of
a use flag.
But that discussion can come after Portage gets use dependencies...
Which, as I understand it, won't be for at least another eighteen months
because three more people have just asked for them.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
sked for them.
>
> I'm a bit confused - does portage already support use-deps or
> does not not ?
https://bugs.gentoo.org/show_bug.cgi?id=2272
Six years and counting.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
and I get the impression that there aren't any particularly strong
feelings either way. So can we get a Council ruling to either kill the
limit and strongly encourage people to fix their code, or keep the
limit and start enforcing it and fixing it in the tree via repoman etc?
--
Ciaran
ng up and untarring to preserve mtimes.
That's not really any good either. The proper solution would be to fix
whatever it is that's mtime-sensitive.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
e
> > about versions
>
> Might I suggest that if PMS is going to be discussed, a copy of
> PMS.pdf actually be available somewhere? Preferably with the
> kdebuild-1 crap stripped out...
Might I suggest that you read the agenda rather than going completely
off topic like last tim
On Thu, 8 May 2008 04:15:10 -0700
Brian Harring <[EMAIL PROTECTED]> wrote:
> If PMS is going to be discussed in some form, it's a fair request
> that folks have an easily readable version.
The relevant sentence was provided. Had you bothered to read the
agenda, you would know
On Thu, 08 May 2008 09:17:08 -0400
Doug Goldstein <[EMAIL PROTECTED]> wrote:
> It's troubling to me that projects are using lzma when it's on disk
> format isn't even final and the project has security issues.
You mean projects like 'GNU tar'?
--
Ciaran McCr
On Thu, 08 May 2008 09:32:34 -0400
Doug Goldstein <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > On Thu, 08 May 2008 09:17:08 -0400
> > Doug Goldstein <[EMAIL PROTECTED]> wrote:
> >> It's troubling to me that projects are using lzma when it'
e telling you the
> > program cannot be started with subtle crashes for symbol collision.
>
> Is there any reason why --as-needed is not enabled "by default"?
--as-needed is fundamentally broken by design and causes legitimate code
to break.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
_broken_ because it breaks this
> case is _quite_ an exaggeration...
Saying it's broken because it goes against an international standard
isn't...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
cally designed to support it.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Fri, 30 May 2008 21:29:26 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > --as-needed is fundamentally broken by design and causes legitimate
> > code to break.
>
> Basically C++ quasi-standard corner cases nobody uses, that happen to
On Sat, 31 May 2008 00:31:22 +0300
Mart Raudsepp <[EMAIL PROTECTED]> wrote:
> On R, 2008-05-30 at 20:20 +0100, Ciaran McCreesh wrote:
> > On Fri, 30 May 2008 21:13:32 +0200
> > Luca Barbato <[EMAIL PROTECTED]> wrote:
> > > Talk to the upstream about
on-ELF
> platforms, should not cause good things for our users to be shot down.
You could say the same thing for -ffast-math...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Fri, 30 May 2008 15:07:43 -0700
Donnie Berkholz <[EMAIL PROTECTED]> wrote:
> On 22:53 Fri 30 May , Ciaran McCreesh wrote:
> > On Sat, 31 May 2008 00:47:44 +0300
> > Mart Raudsepp <[EMAIL PROTECTED]> wrote:
> > > The story that matters here is, that a C++
overed? Have you made
sure that software isn't merely working by fluke? Is Gentoo really that
desperate to turn everyone into a ricer?
I'd bet you could get a pretty long way by shoving -ffast-math into
CFLAGS by default before anyone would notice...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
sn't any
> standard that it violates since it's the default behavior at least
> for 2 platform (one from those who wrote most of the ELF spec...).
> Point the spec, and the paragraph violated.
ISO/IEC 14882:1998 section 3.7.1 paragraph 2.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ft. It even has the same
section and paragraph number.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
es to the linker where necessary for sensible
behaviour was considered acceptable, and with good reason.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Sat, 31 May 2008 02:17:15 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > Linking with as-needed is the stage in which the elimination occurs,
> > and as-needed is the cause of the elimination. So yes, it is
> > related.
>
> The linke
On Sat, 31 May 2008 03:03:42 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > Which is where the design flaw is -- as-needed incorrectly assumes
> > that the only type of dependency between shared objects is a name
> > dependency. This
sing
as-needed. The correct solution is to fix libtool, but that's evidently
beyond the abilities of people who're only interested in increasing
their epenis size by throwing more silly options in config files.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ions in config files.
>
> Then go do it. You don't like the solution folks favor because you
> view another as more "correct and proper", either put up, or shut
> up.
Ah, brilliant. The old "yes, we know we're wrong but we're going to do
it any
what the
libtool problems are... But from the looks of things, plenty of people
are quite happy to jump in and yell when they don't have the slightest
clue what the root problem is, what as-needed changes, what as-needed
breaks or how as-needed is unrelated to the problem. And unfor
uite simple, and if there're any of the above that you didn't
already know then why are you wasting everyone else's time discussing
things in this thread without doing some basic research first?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ol bug would give all the benefits purportedly
> > given by using as-needed, without the drawbacks.
>
> Fact: It hasn't been done forever, and won't be done anytime soon.
And the Debian patch is...?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
I posted earlier in the thread.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
using Foundation and Council rules. For the Council, there
aren't any restrictions on who can nominate or who can run -- GLEP 39
doesn't even include the restriction on only nominating developers.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
d you achieve as a council member?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
I'd like all of the above to justify their slackerness.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
make much sense to approve the
> syntax and then disallowing it by QA :)
As I recall, the logic was that global use flags have a single, well
defined global meaning. Using use.local.desc for *refinements* wouldn't
go against that, but it's a fairly badly defined line.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
bindings is
enabled for app-misc/foo.
But that's rather ugly... There's probably a nicer way of marking it up
using XML.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
).
The current council has raised "never actually deciding anything" to an
art form.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
l"
> to an art form.
If you seriously think I haven't contributed anything useful, you raise
ignorant nonsensical whining to... well, no, it's still just ignorant
nonsensical whining.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
eeds it
(exheres has everything as fatal except where preceeded by 'nonfatal'),
I'm not sure that Portage can just now.
Also note that quite a few packages rely upon the current nonfatal
behaviour, so it'd need to be an EAPI bump...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Sun, 8 Jun 2008 20:48:41 +0530
"Arun Raghavan" <[EMAIL PROTECTED]> wrote:
> On Sun, Jun 8, 2008 at 8:29 PM, Ciaran McCreesh
> <[EMAIL PROTECTED]> wrote:
> [...]
> > This isn't as simple as you think, since quite a few of these
> > utilities are
27; systems break (which is how far these
things get before they're fixed) just leads to lots of annoyed users.
EAPI, plus slowly moving things towards new EAPIs on version bumps once
newer EAPIs are widely supported, is the clean way of doing this.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
le don't care enough to implement most
things, no matter how trivial and useful they are.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ather than blaming Portage's lack of progress for lack of new EAPIs
as they should.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
hat major versions do.
> Major version numbers are written in the postfix, while minor version
> numbers are written in the ebuild itself as EAPI_MINOR="1". So, the
> current EAPI 1 would then be in fact "0.1".
No point. A 0 package manager still couldn't use a 0
On Mon, 09 Jun 2008 09:58:40 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > Anyone thinking that has a very limited understanding of how things
> > work.
>
> Usually in this category you put everybody that disagrees with you,
> no matter
On Mon, 9 Jun 2008 09:26:00 +0100
Roy Marples <[EMAIL PROTECTED]> wrote:
> On Monday 09 June 2008 09:06:24 Ciaran McCreesh wrote:
> > So how, specifically, is PMS "wrongly written", and why hasn't
> > anyone who thinks so bothered to provide details?
>
On Mon, 9 Jun 2008 10:28:57 +0200
"Denis Dupeyron" <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 9, 2008 at 10:06 AM, Ciaran McCreesh
> <[EMAIL PROTECTED]> wrote:
> > On Mon, 09 Jun 2008 09:58:40 +0200
> > Luca Barbato <[EMAIL PROTECTED]> wrote:
> &
On Mon, 09 Jun 2008 10:27:56 +0200
Tiziano Müller <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > No point. A 0 package manager still couldn't use a 0.1 ebuild.
> >
> That's true, it has at least to be aware the there's an EAPI.
> But how does suc
d relevant information on, say,
what a package dep spec looks like.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Mon, 09 Jun 2008 11:49:35 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > On Mon, 09 Jun 2008 10:50:11 +0200
> > Luca Barbato <[EMAIL PROTECTED]> wrote:
> >>> So how, specifically, is PMS "wrongly written", and
On Mon, 09 Jun 2008 12:56:33 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > On Mon, 09 Jun 2008 03:28:03 -0700
> > Josh Saddler <[EMAIL PROTECTED]> wrote:
> >>
> >> Global variables must only contain invariant values (se
space between 'see' and the
reference.
>
> This is demonstrated by the following:
>
>
>
> bunch o'neat code
>
How does "bunch o'neat code" deal with our code file containing things
that XML considers to be reserved characters? That code probably has
ampersands and angle brackets in it.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ch by the way makes my eyes bleed somewhat, you can read it in a
> > very well done PDF.
>
> The pdf renders poorly on xpdf due the fonts latex has, usually I'd
> rather have plain text anyway.
The PDF spec requires that PDF readers have certain fonts available,
and t
to care about EAPIs.
> Along those lines, as I've said before, migrating to a new extension,
> *one-time*, as a solution to this, although not optimal, would be far
> more satisfactory than introducing a series of ever-changing
> extensions.
No it won't. It means future EAPIs will be restricted to some
particular source format.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Most file formats don't have to deal with the compatibility issues that
we do. For example, try feeding this C++ program to a C++0x compiler:
void foo(int x)
{
auto bool requires(x == 1);
}
Or this C++0x program to a C++ compiler:
template
T__ && foo(T_ x)
{
std::list> l;
return x;
}
In both cases, you get user visible messy errors. That's not something
we have the luxury of being able to do.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ise from
> details that do not belong at that (e.g. the filename) level?
And when they do explore, they learn straight away what EAPI is.
> Gentoo is a technical distro, and we encourage users to get technical
> in every other way. Saying that they should remain at the portage
> in
On Mon, 09 Jun 2008 22:09:04 -0600
Joe Peterson <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > And a file extension is far less obscurely complex than enforcing
> > arbitrary syntax restrictions upon ebuilds.
>
> I disagree. One is exposed to devs only as eb
uot;.
It also moves the EAPI definition even further away from the ebuild,
which makes it even harder to work with.
And, of course, it's not backwards compatible, so it'd still need a
file extension change.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
lls the upgrade path completely. No good.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Tue, 10 Jun 2008 11:40:35 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > Kills the upgrade path completely. No good.
>
> Not really, you change the rsync paths and older portage will pick a
> repo that just has the necessary to upg
ng to convert the entire tree to the new EAPI all
in one go every two months?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Tue, 10 Jun 2008 13:13:34 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > So you're volunteering to convert the entire tree to the new EAPI
> > all in one go every two months?
>
> I don't see the need and I won't see the pro
> I am not convinced of this. As others have stated, portage/PM should
> be upgraded with the new capability well in advance of new EAPIs.
But that's exactly what EAPIs are there to solve. Having to wait two
years (or however long Gentoo goes between releases these days) just to
know before you can comment
sensibly on a discussion about package metadata.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
kes comments have meaning
> Most software packages store version information internal to a file
> format. I'm actually not aware of many that put it in the filename.
Most software doesn't have to care about backwards / forwards
compatibility.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ink that filename-vs-first-line is going to make a big
> difference in practical performance.
It's about a factor of five difference in cold-cache resolution
performance for Paludis.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Tue, 10 Jun 2008 19:38:52 +0530
"Arun Raghavan" <[EMAIL PROTECTED]> wrote:
> On Tue, Jun 10, 2008 at 7:30 PM, Ciaran McCreesh
> <[EMAIL PROTECTED]> wrote:
> [...]
> > - it doubles the number of file reads necessary during resolution.
>
> The firs
On Tue, 10 Jun 2008 16:11:49 +0200
Rémi Cardona <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh a écrit :
> > The package manager does not currently source the whole thing with
> > bash to get the EAPI, nor does it open the ebuild file at all for
> > metadata. You'r
>> Not by much. It's just a header.
> >
> >
>
> Do we want to keep the spec so wide open that we support any format
> under the Sun that we fancy? Seems like overgeneralizing to me.
We want to keep it open enough that we're not going to have to go
through yet another backwards compatibility breaking change.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Tue, 10 Jun 2008 19:40:22 +0530
"Arun Raghavan" <[EMAIL PROTECTED]> wrote:
> On Tue, Jun 10, 2008 at 7:32 PM, Ciaran McCreesh
> <[EMAIL PROTECTED]> wrote:
> [...]
> >> I don't think that filename-vs-first-line is going to make a big
> >> dif
em. Being able to get an
ebuild run with the wrong EAPI is utterly irrelevant.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
didn't bother to read...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
for fragile... You might as well say that sticking PN and PV in the
file is fragile and a hack...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
t as part
> of larger operations where doing an open and a getline now just
> speeds up the open and getline that would be executed 500 lines later
> anyway.
paludis -pi anything on a cold cache.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ld use $EAPI as cache filename
> extension.
>
> And that's it, you can get EAPI from the cache, hence no more extra
> reading of ebuild files, and no more perfs issues.
>
> It sounds so simple, am I missing something obvious?
You're missing the cases where th
On Tue, 10 Jun 2008 19:14:11 +0200
Olivier Galibert <[EMAIL PROTECTED]> wrote:
> On Tue, Jun 10, 2008 at 03:02:28PM +0100, Ciaran McCreesh wrote:
> > Except that currently, the ebuild file isn't opened for read. So
> > it's not in memory at all.
>
> Why wo
cope functions is insufficiently concrete?
New global scope functions to replace versionator with something on the
package manager side.
New global scope functions to allow per-cat/pkg eclasses.
Take your pick.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
build can't be visible to older package
managers without breaking them.
So basically it's not a solution at all.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
s not a solution at all.
>
> Name a scenario.
You already named one, and tried to gloss it over as not being the
complete showstopper that it is.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Wed, 11 Jun 2008 09:52:17 +0530
"Arun Raghavan" <[EMAIL PROTECTED]> wrote:
> On Wed, Jun 11, 2008 at 8:44 AM, Ciaran McCreesh
> <[EMAIL PROTECTED]> wrote:
> [...]
> >> Why would you need the EAPI before the time when you actually want
> >> to
vidual test failures where reasonably possible, and will unrestrict
tests when doing version bumps.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
So how are we supposed to handle packages where upstream *require* that
anyone building from source runs 'make check'?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
n doubt, re-read my example above.
No it doesn't. It requires that versions be mappable to a single,
enumerable master version format. Big difference. You could quite
happily add -scm and remove _p in future EAPIs, for example.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
he versioning
> rules of an eapi.
"Must be a superset" being wrong does not mean "entirely arbitrary
changes are OK" is right.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Wed, 11 Jun 2008 07:39:53 +0200
Rémi Cardona <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh a écrit :
> > So how are we supposed to handle packages where upstream *require*
> > that anyone building from source runs 'make check'?
>
> If it's required to
On Wed, 11 Jun 2008 07:46:39 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > On Tue, 10 Jun 2008 22:33:41 -0700
> > Brian Harring <[EMAIL PROTECTED]> wrote:
> >> Lay out how .006/.6 would work properly *per* eapi. As I clarified
>
On Wed, 11 Jun 2008 07:48:06 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > On Wed, 11 Jun 2008 06:24:18 +0200
> > Luca Barbato <[EMAIL PROTECTED]> wrote:
> >> People will (and should) have -test in FEATURES anyway, good
> >
care.
The whole mess started because src_test was introduced late on, but
before EAPIs, so there was no incremental way of making tests usable.
Enforcing src_test in a "you must explicitly say so if your package's
test suites are expected to fail" way on an EAPI bump is a clean way
ing for mocking on -dev.
Had you bothered to write even trivial test suites for EAPI 1, you'd've
found at least one major bug straight away. Do everyone a favour and
write yourself a load of unit tests for every bit of changed
functionality in EAPI 1.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
compiler that generates
broken code that would force you to reinstall a working compiler by
hand when the package manager gets h0rked.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Wed, 11 Jun 2008 07:58:44 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > Oh, so Gentoo has decided that basic QA is another 'poor programming
> > practice' now?
>
> Having a good testsuite is part of the QA, having it not failin
501 - 600 of 3510 matches
Mail list logo
