Mailing List Archive

[GLEP 55] EAPI subdirectories instead of file name suffixes
Piotr Jaroszyński kirjoitti:
> This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds (for
> example, foo-1.2.3.ebuild-1).

It seems many people don't like the idea of having it in the filename
but how about having subdirectories for different eapis. This should
even be faster for the package manager as it can just ignore the
directories it can't understand instead of having to parse the file names.

example:

${PORTDIR}/<category>/<pkg>/eapiX/

Regards,
Petteri
Re: [GLEP 55] EAPI subdirectories instead of file name suffixes [ In reply to ]
On Saturday 22 of December 2007 02:41:02 Petteri Räty wrote:
> Piotr Jaroszyński kirjoitti:
> > This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds
> > (for example, foo-1.2.3.ebuild-1).
>
> It seems many people don't like the idea of having it in the filename

Seems you are counting the posts, not the people.

> but how about having subdirectories for different eapis. This should
> even be faster for the package manager as it can just ignore the
> directories it can't understand instead of having to parse the file names.

It was already proposed, but didn't seem to get much support. It is equivalent
to using the suffixes, but I see it rather as perfomarnce hit, not
improvement. The package manger would have to look for ebuilds in the main
dir and all the subdirs in case it doesn't have/can't use the cache.

--
Best Regards,
Piotr Jaroszyński
--
gentoo-dev@gentoo.org mailing list
Re: [GLEP 55] EAPI subdirectories instead of file name suffixes [ In reply to ]
On Sat, 22 Dec 2007 03:41:02 +0200
Petteri Räty <betelgeuse@gentoo.org> wrote:
> Piotr Jaroszyński kirjoitti:
> > This GLEP proposes usage of EAPI-suffixed file extensions for
> > ebuilds (for example, foo-1.2.3.ebuild-1).
>
> It seems many people don't like the idea of having it in the filename
> but how about having subdirectories for different eapis. This should
> even be faster for the package manager as it can just ignore the
> directories it can't understand instead of having to parse the file
> names.
>
> example:
>
> ${PORTDIR}/<category>/<pkg>/eapiX/

In terms of what it does and doesn't allow, this one's equivalent. But
it has some new disadvantages:

* It's several more directory reads. This is a measurable performance
hit on something that's already i/o bound.

* It's harder to work with for developers. Ebuilds are no longer all in
the same place, and it's harder to see what you're working with.

On a subjective niceness scale, I'd suspect that the file extension is
less unnice.

--
Ciaran McCreesh
Re: [GLEP 55] EAPI subdirectories instead of file name suffixes [ In reply to ]
Piotr Jaroszyński wrote:
> The package manger would have to look for ebuilds in the main
> dir and all the subdirs in case it doesn't have/can't use the cache.

No, it would have to check only for subdirectories named after known and
supported EAPIs.

Cheers,
-jkt

--
cd /local/pub && more beer > /dev/mouth
Re: [GLEP 55] EAPI subdirectories instead of file name suffixes [ In reply to ]
On Sat, Dec 22, 2007 at 07:09:30AM +0000, Ciaran McCreesh wrote:
> On Sat, 22 Dec 2007 03:41:02 +0200
> Petteri Räty <betelgeuse@gentoo.org> wrote:
> > Piotr Jaroszyński kirjoitti:
> > > This GLEP proposes usage of EAPI-suffixed file extensions for
> > > ebuilds (for example, foo-1.2.3.ebuild-1).
> >
> > It seems many people don't like the idea of having it in the filename
> > but how about having subdirectories for different eapis. This should
> > even be faster for the package manager as it can just ignore the
> > directories it can't understand instead of having to parse the file
> > names.
> >
> > example:
> >
> > ${PORTDIR}/<category>/<pkg>/eapiX/
>
> In terms of what it does and doesn't allow, this one's equivalent. But
> it has some new disadvantages:
>
> * It's several more directory reads. This is a measurable performance
> hit on something that's already i/o bound.

Among other things, because readdirs cannot be neither readahead nor
'advised'. Which is STUPIDLY slow. So adding yet another directory to
the hierarchy is quite silly.

- ferdy

--
Fernando J. Pereda Garcimartín
20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4
Re: [GLEP 55] EAPI subdirectories instead of file name suffixes [ In reply to ]
On Saturday 22 of December 2007 10:50:40 Jan Kundrát wrote:
> Piotr Jaroszyński wrote:
> > The package manger would have to look for ebuilds in the main
> > dir and all the subdirs in case it doesn't have/can't use the cache.
>
> No, it would have to check only for subdirectories named after known and
> supported EAPIs.

Not really, we still want to show ebuilds with unsupported EAPI as being
masked, but I agree it will have to check only eapiX subdirs. It's still a
performance hit though.

--
Best Regards,
Piotr Jaroszyński
--
gentoo-dev@gentoo.org mailing list
Re: [GLEP 55] EAPI subdirectories instead of file name suffixes [ In reply to ]
Piotr Jaroszy?ski wrote:

> On Saturday 22 of December 2007 02:41:02 Petteri Räty wrote:
>> Piotr Jaroszy?ski kirjoitti:
>> > This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds
>> > (for example, foo-1.2.3.ebuild-1).
>>
>> It seems many people don't like the idea of having it in the filename
>
> Seems you are counting the posts, not the people.
>
>> but how about having subdirectories for different eapis. This should
>> even be faster for the package manager as it can just ignore the
>> directories it can't understand instead of having to parse the file
>> names.
>
> It was already proposed, but didn't seem to get much support.
That would be counting posts, not people. It just hasn't been discussed.

> It is
> equivalent to using the suffixes, but I see it rather as perfomarnce hit,
> not improvement. The package manger would have to look for ebuilds in the
> main dir and all the subdirs in case it doesn't have/can't use the cache.
>
Yeah but this isn't about performance (or so I heard. I took that to mean it
was about ebuilds which can't be sourced, but you might want to check
exactly what McCreesh meant, since I am apparently incapable of
understanding his missives.)

Given that, the subdirectories would do the job fine, and end-users don't
have to worry about building the cache anyway.


--
gentoo-dev@gentoo.org mailing list