FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 12-28-2007, 11:28 AM
Ciaran McCreesh
 
Default EAPI definition Was: Use EAPI-suffixed ebuilds (.ebuild-EAPI)

On Fri, 28 Dec 2007 13:25:13 +0100
"Santiago M. Mola" <coldwind@gentoo.org> wrote:
> On Dec 28, 2007 1:03 PM, Ciaran McCreesh
> <ciaran.mccreesh@blueyonder.co.uk> wrote:
> > There's no particular reason that new
> > version formats can't be introduced in a new EAPI so long as the
> > version strings don't appear in ebuilds using older EAPIs or in
> > profiles. Ditto for naming rules.
>
> Errr... so should we use new files in profiles for such new formats?
> (for example, p.masking an ebuild with a new version format).

Possibly. Currently there's simply no way of doing it, nor of using
non-EAPI-0 features anywhere in profiles (you can't, for example, use
slot deps in package.mask).

--
Ciaran McCreesh
 
Old 12-28-2007, 11:45 AM
"Santiago M. Mola"
 
Default EAPI definition Was: Use EAPI-suffixed ebuilds (.ebuild-EAPI)

On Dec 28, 2007 1:28 PM, Ciaran McCreesh
<ciaran.mccreesh@blueyonder.co.uk> wrote:
> On Fri, 28 Dec 2007 13:25:13 +0100
> "Santiago M. Mola" <coldwind@gentoo.org> wrote:
> > On Dec 28, 2007 1:03 PM, Ciaran McCreesh
> > <ciaran.mccreesh@blueyonder.co.uk> wrote:
> > > There's no particular reason that new
> > > version formats can't be introduced in a new EAPI so long as the
> > > version strings don't appear in ebuilds using older EAPIs or in
> > > profiles. Ditto for naming rules.
> >
> > Errr... so should we use new files in profiles for such new formats?
> > (for example, p.masking an ebuild with a new version format).
>
> Possibly. Currently there's simply no way of doing it, nor of using
> non-EAPI-0 features anywhere in profiles (you can't, for example, use
> slot deps in package.mask).
>

It'd be nice to agree a new profile format before accepting version
format changes.

In the case of slot deps, it'd be desirable to use them in
package.mask, just desirable. But with version format changes we're
introducing ebuilds which can't be handled in package.mask, that's a
great loss of functionality.

GLEPs 54 and 55 could wait until we have figured out how to apply them
properly and without loss of current functionality.

--
Santiago M. Mola
Jabber ID: cooldwind@gmail.com
--
gentoo-dev@gentoo.org mailing list
 
Old 12-31-2007, 01:46 PM
Marius Mauch
 
Default EAPI definition Was: Use EAPI-suffixed ebuilds (.ebuild-EAPI)

On Fri, 28 Dec 2007 12:03:12 +0000
Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> wrote:

> On Thu, 27 Dec 2007 23:26:27 +0100
> Luca Barbato <lu_zero@gentoo.org> wrote:
> > Marius Mauch wrote:
> > > Nope. EAPI (from my POV) defines the API that a package manager has
> > > to export to an ebuild/eclass. That includes syntax and semantics
> > > of exported and expected functions and variables (IOW the content
> > > of ebuilds/eclasses), but does not contain naming and versioning
> > > rules (as those impact cross-package relationships).
> >
> > This restricted definition is ok for everybody?
>
> The restricted definition is certainly OK, but I'm not convinced that
> the restriction is necessary. There's no particular reason that new
> version formats can't be introduced in a new EAPI so long as the
> version strings don't appear in ebuilds using older EAPIs or in
> profiles.

The issue is with comparison rules. For the current use case that's not
an issue as it's simply a superset, so we could just use the new rules
for everything. But if the rules are changed in an incompatible way,
which rules would be used to compare version(EAPI_X) with version(EAPI_Y)?

> Ditto for naming rules.

Those are even more of an issue, as they apply before we know the
eventual EAPI (need to access the category/package directory before you
can parse the ebuild filename)

Marius
--
gentoo-dev@gentoo.org mailing list
 
Old 12-31-2007, 02:09 PM
Ciaran McCreesh
 
Default EAPI definition Was: Use EAPI-suffixed ebuilds (.ebuild-EAPI)

On Mon, 31 Dec 2007 15:46:06 +0100
Marius Mauch <genone@gentoo.org> wrote:
> The issue is with comparison rules. For the current use case that's
> not an issue as it's simply a superset, so we could just use the new
> rules for everything. But if the rules are changed in an incompatible
> way, which rules would be used to compare version(EAPI_X) with
> version(EAPI_Y)?

You pretty much have to have a way of mapping an EAPI version onto an
absolute version if you want to handle it sanely.

> > Ditto for naming rules.
>
> Those are even more of an issue, as they apply before we know the
> eventual EAPI (need to access the category/package directory before
> you can parse the ebuild filename)

Mmm, no. You have some concept of a superset of all supported naming
rules, then refine once you've extracted the EAPI.

--
Ciaran McCreesh
 
Old 01-01-2008, 03:50 AM
Marius Mauch
 
Default EAPI definition Was: Use EAPI-suffixed ebuilds (.ebuild-EAPI)

On Mon, 31 Dec 2007 15:09:33 +0000
Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> wrote:

> On Mon, 31 Dec 2007 15:46:06 +0100
> Marius Mauch <genone@gentoo.org> wrote:
> > The issue is with comparison rules. For the current use case that's
> > not an issue as it's simply a superset, so we could just use the new
> > rules for everything. But if the rules are changed in an incompatible
> > way, which rules would be used to compare version(EAPI_X) with
> > version(EAPI_Y)?
>
> You pretty much have to have a way of mapping an EAPI version onto an
> absolute version if you want to handle it sanely.

Right, and that's likely to cause a mess in the long run IMO.

> > > Ditto for naming rules.
> >
> > Those are even more of an issue, as they apply before we know the
> > eventual EAPI (need to access the category/package directory before
> > you can parse the ebuild filename)
>
> Mmm, no. You have some concept of a superset of all supported naming
> rules, then refine once you've extracted the EAPI.

Assuming the current package manager supports all used EAPIs, otherwise
a formerly invalid name could still break it.

Marius
--
gentoo-dev@gentoo.org mailing list
 
Old 01-01-2008, 02:42 PM
Ciaran McCreesh
 
Default EAPI definition Was: Use EAPI-suffixed ebuilds (.ebuild-EAPI)

On Tue, 1 Jan 2008 05:50:11 +0100
Marius Mauch <genone@gentoo.org> wrote:
> > You pretty much have to have a way of mapping an EAPI version onto
> > an absolute version if you want to handle it sanely.
>
> Right, and that's likely to cause a mess in the long run IMO.

Eh, it's already necessary if package managers want to support things
like CPAN natively. It's not too big a deal.

> > Mmm, no. You have some concept of a superset of all supported naming
> > rules, then refine once you've extracted the EAPI.
>
> Assuming the current package manager supports all used EAPIs,
> otherwise a formerly invalid name could still break it.

'Twould just have to ignore them.

--
Ciaran McCreesh
 

Thread Tools




All times are GMT. The time now is 03:50 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org