> What is proposed in glep-55 seems to aim to solve both issues at the
> same time (it isn't stated) by switching file extension every 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
On Mon, Feb 23, 2009 at 09:38:06AM +0100, Tiziano M??ller wrote:
> > What is proposed in glep-55 seems to aim to solve both issues at the
> > same time (it isn't stated) by switching file extension every time the
> > eapi is changed. This is slightly against the principle of the least
> > surpri
Tiziano Müller wrote:
>> What is proposed in glep-55 seems to aim to solve both issues at the
>> same time (it isn't stated) by switching file extension every time the
>> eapi is changed. This is slightly against the principle of the least
>> surprise and apparently is disliked by enough peopl
Am Montag, den 23.02.2009, 22:25 +1300 schrieb Alistair Bush:
>
> Tiziano Müller wrote:
> >> What is proposed in glep-55 seems to aim to solve both issues at the
> >> same time (it isn't stated) by switching file extension every time the
> >> eapi is changed. This is slightly against the princip
On Mon, Feb 23, 2009 at 7:02 PM, Tiziano Müller wrote:
> Am Montag, den 23.02.2009, 22:25 +1300 schrieb Alistair Bush:
>>
>> Tiziano Müller wrote:
>> >> What is proposed in glep-55 seems to aim to solve both issues at the
>> >> same time (it isn't stated) by switching file extension every time the
On Mon, Feb 23, 2009 at 07:28:00PM +0900, Douglas Anderson wrote:
> On Mon, Feb 23, 2009 at 7:02 PM, Tiziano Müller wrote:
> > Am Montag, den 23.02.2009, 22:25 +1300 schrieb Alistair Bush:
> >>
> >> Tiziano Müller wrote:
> >> >> What is proposed in glep-55 seems to aim to solve both issues at the
Tiziano Müller wrote:
What is proposed in glep-55 seems to aim to solve both issues at the
same time (it isn't stated) by switching file extension every 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
On Mon, Feb 23, 2009 at 02:21:33PM +0100, Luca Barbato wrote:
> Tiziano M??ller wrote:
>>> What is proposed in glep-55 seems to aim to solve both issues at the same
>>> time (it isn't stated) by switching file extension every time the eapi is
>>> changed. This is slightly against the principle of
Brian Harring posted 20090223085232.ga6...@hrair,
excerpted below, on Mon, 23 Feb 2009 00:52:32 -0800:
> On Mon, Feb 23, 2009 at 09:38:06AM +0100, Tiziano M??ller wrote:
>> [quoting...]
>>> What is proposed in glep-55 seems to aim to solve both issues at the
>>> same time (it isn't stated) by sw
On Mon, 23 Feb 2009 04:26:49 -0800
Brian Harring wrote:
> There also is the angle that deploying g55 requires waiting at least
> a full stage release (~year, at least by the old standards) to ensure
> people aren't screwed by the repository changing formats
> (unversioned!) under their feet.
No
See the patch.
--
cd /local/pub && more beer > /dev/mouth
--- generation1-deprecation.orig2009-02-23 14:50:37.920591164 +0100
+++ generation1-deprecation 2009-02-23 14:51:25.180617090 +0100
@@ -21,9 +21,9 @@
emerge -av --depclean virtual/jdk:1.4
-If don't need virtual/jdk:1.4 any
On Mon, 23 Feb 2009 03:15:03 +0100
Luca Barbato wrote:
> Let's try to start with a common workflow for the user:
> - an user with an ancient version of portage syncs
> - it requires a package
> - it looks at the cache ($portdir/metadata/cache/)
> - picks the best entry from the ones showing an eap
On Mon, Feb 23, 2009 at 01:50:10PM +, Ciaran McCreesh wrote:
> On Mon, 23 Feb 2009 04:26:49 -0800
> Brian Harring wrote:
> > There also is the angle that deploying g55 requires waiting at least
> > a full stage release (~year, at least by the old standards) to ensure
> > people aren't screwed
On Mon, 23 Feb 2009 06:15:25 -0800
Brian Harring wrote:
> > No it doesn't. It's transparent to users using an older package
> > manager.
>
> Would be useful if someone pulled older portage versions and checked
> exactly what they do in this case- explode, behave, etc (manifest
> behaviour inclu
Douglas Anderson wrote:
No one wants to be working with ebuild-29 or something like that in a
few years and trying to figure out which feature came in which EAPI.
Instead of bumping EAPI for each little change, save them up and bump
no more than once a year or less, each bump bringing in some maj
On Mon, 23 Feb 2009 09:28:06 -0500
Richard Freeman wrote:
> I got the impression that if anything there is a desire to allow
> EAPIs to change more offen, and not less. And these changes could
> become more dramatic.
But we're still only talking maybe three new EAPIs a year.
> Also - keep in mi
Ciaran McCreesh wrote:
On Mon, 23 Feb 2009 03:15:03 +0100
Luca Barbato wrote:
Let's try to start with a common workflow for the user:
- an user with an ancient version of portage syncs
- it requires a package
- it looks at the cache ($portdir/metadata/cache/)
- picks the best entry from the one
On Mon, 23 Feb 2009 15:46:24 +0100
Luca Barbato wrote:
> >> Apparently we do not have any issue...
> >
> > ...assuming the metadata cache is valid. That isn't always the case.
>
> When it isn't?
Every now and again (probably after someone changes eutils...), rsync
mirrors end up shipping a load
Richard Freeman wrote:
I still don't see why we need to be encoding metadata in filenames. PERL
doesn't care what a file extension is, python doesn't care, bzip2
doesn't care, tar doesn't care, gzip doesn't care, and even ld-linux.so
doesn't care. I'm sure that in at least some of these cases
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mounir Lamouri wrote:
> Hi,
>
> I was writing a trivial version bump for net-voip/gnugk-2.2.8 (bug
> #258518) but upstream added a file named p2pnat_license.txt (see
> http://dpaste.com/123376/) This file looks to authorize gnugk project
> (and users)
On Mon, 23 Feb 2009 08:43:09 -0700
Steve Dibb wrote:
> Plus, I don't really grasp the whole "we have to source the whole
> ebuild to know the EAPI version" argument. It's one variable, in one
> line. Can't a simple parser get that and go from there?
Not true. This is entirely legal:
In pkg-1.eb
On Mon, Feb 23, 2009 at 10:44 AM, Marijn Schouten (hkBst)
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Mounir Lamouri wrote:
>> Hi,
>>
>> I was writing a trivial version bump for net-voip/gnugk-2.2.8 (bug
>> #258518) but upstream added a file named p2pnat_license.txt (see
>> http:/
On Mon, 23 Feb 2009 08:43:09 -0700
Steve Dibb wrote:
> Plus, I don't really grasp the whole "we have to source the whole
> ebuild to know the EAPI version" argument. It's one variable, in one
> line. Can't a simple parser get that and go from there?
The problem is that its technically allowed f
On Mon, 23 Feb 2009 17:06:17 +0100
Peter Alfredsen wrote:
> To be honest I see no good reason for allowing manipulation of it, but
> I'm sure other people will tell me why adding this requirement at this
> point is wrong
There's not really a good reason to allow manipulating it (and,
obviously, w
On Mon, 23 Feb 2009 15:53:20 +
Ciaran McCreesh wrote:
> On Mon, 23 Feb 2009 08:43:09 -0700
> Steve Dibb wrote:
> > Plus, I don't really grasp the whole "we have to source the whole
> > ebuild to know the EAPI version" argument. It's one variable, in
> > one line. Can't a simple parser get t
On Mon, 23 Feb 2009 17:13:16 +0100
Alexis Ballier wrote:
> Which begs the question: is it really worth allowing it?
> If we only allow constant assignments (which is an implicit
> restriction in the file extension version) then this can be parsed
> easily with grep/tr/awk/etc and can be the magic
On Mon, 23 Feb 2009 16:19:56 +
Ciaran McCreesh wrote:
> On Mon, 23 Feb 2009 17:13:16 +0100
> Alexis Ballier wrote:
> > Which begs the question: is it really worth allowing it?
> > If we only allow constant assignments (which is an implicit
> > restriction in the file extension version) then
On Mon, 23 Feb 2009 17:48:27 +0100
Alexis Ballier wrote:
> > ...and then we have to do the whole thing again every time something
> > new crops up.
>
> Please give an example because I fail to see how.
New version suffix rules. New bash versions. New package naming rules.
Partially composable EA
On Mon, Feb 23, 2009 at 7:53 AM, Ciaran McCreesh
wrote:
> On Mon, 23 Feb 2009 08:43:09 -0700
> Steve Dibb wrote:
>> Plus, I don't really grasp the whole "we have to source the whole
>> ebuild to know the EAPI version" argument. It's one variable, in one
>> line. Can't a simple parser get that an
On Mon, 23 Feb 2009 11:02:17 -0800
Alec Warner wrote:
> > In foo.eclass:
> >
> >EAPI="3"
>
> This is not legal, the devmanual[1] explicitly states that it is not
> legal to set EAPI in an eclass.
That's purely a QA thing, and it only applies to repositories that
follow Gentoo's QA rules. It'
On Mon, 23 Feb 2009 08:43:09 -0700
Steve Dibb wrote:
> Richard Freeman wrote:
> > I still don't see why we need to be encoding metadata in filenames.
> > PERL doesn't care what a file extension is, python doesn't care,
> > bzip2 doesn't care, tar doesn't care, gzip doesn't care, and even
> > ld-l
Ciaran McCreesh wrote:
> On Mon, 23 Feb 2009 17:48:27 +0100
> Alexis Ballier wrote:
>>> ...and then we have to do the whole thing again every time something
>>> new crops up.
>> Please give an example because I fail to see how.
>
> New version suffix rules. New bash versions. New package naming r
On Mon, 23 Feb 2009 21:30:04 +0200
Petteri Räty wrote:
> > 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 have a whole bunch of requested features implemented by now.
> >
>
> I doubt Portage would have
Hi,
Ulrich Mueller :
> > On Fri, 20 Feb 2009, Christian Faulhammer wrote:
>
> > $ time (bzr diff --old lp:bzr-gentoo-overlay \
> > --new /media/disk/bzr-overlay/|diffstat)
>
> > real0m50.088s
>
> This is prohibitive. Drop it completely, or enable it only if some
> environment varia
Hi,
René 'Necoro' Neumann :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Jorge Manuel B. S. Vicetto schrieb:
> > Hi.
> >
> > Christian Faulhammer wrote:
> >> Hi,
> >>
> >> a user maintained a Bazaar overlay for some time now and introduced
> >> some changes to bzr eclass, I would like
Ryan Hill wrote:
On Mon, 23 Feb 2009 08:43:09 -0700
Steve Dibb wrote:
Richard Freeman wrote:
I still don't see why we need to be encoding metadata in filenames.
PERL doesn't care what a file extension is, python doesn't care,
bzip2 doesn't care, tar doesn't care, gzip doesn't care, and even
l
On Mon, 23 Feb 2009 21:51:11 +0100
Luca Barbato wrote:
> > 2. (with myeclass.eclass containing EAPI=2)
> > -
> > EAPI=1
> > inherit myeclass
>
> Invalid
QA violation, but legal and a pain in the ass.
> > 3. (with myeclass.eclass containing EAPI=2)
> > -
> > EAPI=5
> > inherit myeclass
>
On Mon, 23 Feb 2009 20:54:38 +
Ciaran McCreesh wrote:
> On Mon, 23 Feb 2009 21:51:11 +0100
> Luca Barbato wrote:
> > > 2. (with myeclass.eclass containing EAPI=2)
> > > -
> > > EAPI=1
> > > inherit myeclass
> >
> > Invalid
>
> QA violation, but legal and a pain in the ass.
I didn't th
On Mon, 23 Feb 2009 16:15:25 -0600
Ryan Hill wrote:
> Can we ban eclasses from setting EAPI? Is there any case where it
> would be sane?
It's already banned from a QA perspective, but from a package manager
perspective people have done it in the past and possibly still do do
it, and the spec doe
On Mon, 23 Feb 2009 16:15:25 -0600
Ryan Hill wrote:
> On Mon, 23 Feb 2009 20:54:38 +
> Ciaran McCreesh wrote:
>
> > On Mon, 23 Feb 2009 21:51:11 +0100
> > Luca Barbato wrote:
> > > > 2. (with myeclass.eclass containing EAPI=2)
> > > > -
> > > > EAPI=1
> > > > inherit myeclass
> > >
>
server15
custom-cflags 10
logrotate 9
gsm 9
semantic-desktop 9
webkit8
html 7
multislot 7
nautilus 7
audacious
Markus Meier writes:
> semantic-desktop: Semantic desktop allows for storage of digital
> information and its metadata to allow the user to express his personal
> mental models, making all in formation become intuitively accessible
I find this description pretty content-free and hand-wavy. I usu
Ryan Hill wrote:
Richard Freeman wrote:
I'm
actually hard pressed to think of any unix-based software that uses
the filename to store a mandatory file format versioning specifier
of some kind.
$ ls /usr/lib
I was referring to a file FORMAT versioning scheme - not a file CONTENT
versioning
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
Ciaran McCreesh wrote:
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.
I suppose I'm exaggerating a little
On Mon, 23 Feb 2009 19:17:19 -0500
Richard Freeman wrote:
> It just seems like it isn't the best solution. You can get the same
> effect by just sticking something in a comment line a few lines into
> the ebuild in a fixed position.
No you can't. It doesn't work with existing package managers,
Alistair Bush wrote:
> Tiziano Müller wrote:
> > Instead of switching file extension every time the eapi is changed
> > you could also increment it only when a new EAPI breaks sourcing
> > the ebuild compared to the requirements of the prior EAPI.
> > (This way you'd in fact split EAPI into a majo
Ciaran McCreesh wrote:
On Mon, 23 Feb 2009 19:17:19 -0500
Richard Freeman wrote:
It just seems like it isn't the best solution. You can get the same
effect by just sticking something in a comment line a few lines into
the ebuild in a fixed position.
No you can't. It doesn't work with existi
On Tue, Feb 24, 2009 at 4:52 AM, Josh Sled wrote:
> (Also, I note in passing the existing kde-base/pykde4 use.local.desc has
> a tyop of "Nemomuk".)
>
Oh, sweet irony :)
--
~Nirbheek Chauhan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Josh Sled wrote:
> Markus Meier writes:
>> semantic-desktop: Semantic desktop allows for storage of digital
>> information and its metadata to allow the user to express his personal
>> mental models, making all in formation become intuitively accessib
On Tuesday 24 of February 2009 00:22:39 Josh Sled wrote:
> To that end, please allow me to suggest:
> "Cross-KDE support for file metadata indexing via nepomuk and soprano."
>
> If you don't want to couple the message to those particular packages,
> then maybe just reference the "NEPOMUK project"
On Sunday 22 February 2009 18:03:23 Dawid Węgliński wrote:
> On Sunday 22 of February 2009 23:39:11 Mike Frysinger wrote:
> > On Sunday 22 February 2009 17:30:09 Dawid Węgliński wrote:
> > > On Sunday 22 of February 2009 00:27:10 Mike Frysinger wrote:
> > > > looks like bash-4.0 has broken semicolo
I was looking to do a workaround on a per compiler basis.
I'm looking at toolchain-funcs.eclass, and specifically
${gcc-fullversion}. I've got a broken ebuild (dhcdbd) which requires
-U_FORTIFY_SOURCE to compile correctly with GCC 4.3.3. But reading
tells me that I should not use this eclass to s
Luca Barbato wrote:
Ciaran McCreesh wrote:
Because your proposal addresses none of the underlying problems which
GLEP 55 was created to solve.
let's get some numbers to have an idea of the dimension of the problem.
domino portage # wc -l /dev/shm/eapi_files.list
2854 /dev/shm/eapi_files.list
On Tuesday 24 February 2009 00:57:25 Andrew D Kirch wrote:
> I was looking to do a workaround on a per compiler basis.
> I'm looking at toolchain-funcs.eclass, and specifically
> ${gcc-fullversion}. I've got a broken ebuild (dhcdbd) which requires
> -U_FORTIFY_SOURCE to compile correctly with GCC
55 matches
Mail list logo
