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 09-02-2012, 02:45 PM
Fabio Erculiani
 
Default EAPI 5+: split PDEPEND introducing SDEPEND

Hi,
this is actually a fork of the HDEPEND thread (sorry for having
diverged that much there).
As I wrote in the other thread, the problem with PDEPEND is that there
are two (or more) semantics:

- PDEPENDs used as "suggestions" but yet being considered in the
depgraph and actually installed. Usually "suggestion" PDEPENDs are
just packages providing extra features, not strictly required for the
package to work at all.
- PDEPENDs used for breaking dependency cycles (no problem with that).

That is why I'd like to propose to introduce SDEPEND, with the
following, simple, semantics:
dependencies listed in SDEPEND are not required at build time nor
strictly at runtime and they just enable more features in the
installed application. There can be "use?" literals and by default,
PMS should not pull them in in the dependencies calculation if not
specifically asked (through argument or configuration file or else --
like it happens with binpkgs and --with-bdeps).

A bunch of advantages over GLEP 62:
- Simplicity (really, as in KISS). SDEPENDs are easier to understand
and deal with, both at PMS (code) and user levels. They are also
straightforward to use in ebuilds (dev) and through emerge (user). [1]
- The USE flags meaning doesn't really get "stretched" introducing
obscure, unknown and dangerous possible side effects when deployed in
the real(tm) world. I understand that there is some level of risk with
SDEPENDs as well, but we've seen them already in Exherbo and they seem
to work fine there (I've been told this).
- Doesn't preclude the implementation of GLEP 62 anyway. SDEPENDs are
just "suggested" dependencies after all!
- No need to introduce funky cache invalidation logic for PMS
aggressively using caching at several layers of their stack and that
guarantee a consistent depgraph for the installed pkgs repository as
well [2].
- Fixes the "dissociative identity disorder" of PDEPEND ;-).

Disadvantages:
- If SDEPEND contains USE flags, these are written in stone and cannot
be changed without a rebuild. This is generally fine for source
packages, a bit less for binpkgs, but not really a big deal IMO.
- Not as "elastic" as GLEP 62 USE flags, but neither *DEPENDs are
- mgorny will hate me (eheheheh)

Discuss.

[1] It took me more than 5 minutes to understand how GLEP 62 works in
practice and this is not really good to me, for a simple feature like
this.
[2] From GLEP 62 page: "and it is not strictly required that a package
manager must ensure that the dependency graph is still consistent
afterwards".
--
Fabio Erculiani
 
Old 09-02-2012, 02:57 PM
hasufell
 
Default EAPI 5+: split PDEPEND introducing SDEPEND

On 09/02/2012 04:45 PM, Fabio Erculiani wrote:
> Hi,
> this is actually a fork of the HDEPEND thread (sorry for having
> diverged that much there).
> As I wrote in the other thread, the problem with PDEPEND is that there
> are two (or more) semantics:
>
> - PDEPENDs used as "suggestions" but yet being considered in the
> depgraph and actually installed. Usually "suggestion" PDEPENDs are
> just packages providing extra features, not strictly required for the
> package to work at all.
> - PDEPENDs used for breaking dependency cycles (no problem with that).
>
> That is why I'd like to propose to introduce SDEPEND, with the
> following, simple, semantics:
> dependencies listed in SDEPEND are not required at build time nor
> strictly at runtime and they just enable more features in the
> installed application. There can be "use?" literals and by default,
> PMS should not pull them in in the dependencies calculation if not
> specifically asked (through argument or configuration file or else --
> like it happens with binpkgs and --with-bdeps).
>
> A bunch of advantages over GLEP 62:
> - Simplicity (really, as in KISS). SDEPENDs are easier to understand
> and deal with, both at PMS (code) and user levels. They are also
> straightforward to use in ebuilds (dev) and through emerge (user). [1]
> - The USE flags meaning doesn't really get "stretched" introducing
> obscure, unknown and dangerous possible side effects when deployed in
> the real(tm) world. I understand that there is some level of risk with
> SDEPENDs as well, but we've seen them already in Exherbo and they seem
> to work fine there (I've been told this).
> - Doesn't preclude the implementation of GLEP 62 anyway. SDEPENDs are
> just "suggested" dependencies after all!
> - No need to introduce funky cache invalidation logic for PMS
> aggressively using caching at several layers of their stack and that
> guarantee a consistent depgraph for the installed pkgs repository as
> well [2].
> - Fixes the "dissociative identity disorder" of PDEPEND ;-).
>
> Disadvantages:
> - If SDEPEND contains USE flags, these are written in stone and cannot
> be changed without a rebuild. This is generally fine for source
> packages, a bit less for binpkgs, but not really a big deal IMO.
> - Not as "elastic" as GLEP 62 USE flags, but neither *DEPENDs are
> - mgorny will hate me (eheheheh)
>
> Discuss.
>
> [1] It took me more than 5 minutes to understand how GLEP 62 works in
> practice and this is not really good to me, for a simple feature like
> this.
> [2] From GLEP 62 page: "and it is not strictly required that a package
> manager must ensure that the dependency graph is still consistent
> afterwards".


Why not introduce a global useflag such as "suggested-deps" which
complies with GLEP 62 meaning it will be in IUSE_RUNTIME.
 
Old 09-02-2012, 03:09 PM
Fabio Erculiani
 
Default EAPI 5+: split PDEPEND introducing SDEPEND

On Sun, Sep 2, 2012 at 4:57 PM, hasufell <hasufell@gentoo.org> wrote:
>
>
> Why not introduce a global useflag such as "suggested-deps" which
> complies with GLEP 62 meaning it will be in IUSE_RUNTIME.
>

How do you manage to fix the PDEPEND "identity disorder" problem then?
Teaching devs to move to GLEP 62 is much harder than just telling them
to move dep strings to more appropriate locations.
Moreover, your solution just makes the USE flags abuse situation
worse: there are packages that use USE flags just to include extra,
optional packages in the dependencies... See USE=bluetooth in
net-misc/networkmanager for example (this is what I mean with USE
flags abuse, actually).
I'm not saying that SDEPEND is the best one-size-fits-all solution but
you may agree that's the simplest and most effective one.

--
Fabio Erculiani
 
Old 09-02-2012, 03:11 PM
Michał Górny
 
Default EAPI 5+: split PDEPEND introducing SDEPEND

On Sun, 2 Sep 2012 16:45:12 +0200
Fabio Erculiani <lxnay@gentoo.org> wrote:

> Hi,
> this is actually a fork of the HDEPEND thread (sorry for having
> diverged that much there).
> As I wrote in the other thread, the problem with PDEPEND is that there
> are two (or more) semantics:
>
> - PDEPENDs used as "suggestions" but yet being considered in the
> depgraph and actually installed. Usually "suggestion" PDEPENDs are
> just packages providing extra features, not strictly required for the
> package to work at all.
> - PDEPENDs used for breaking dependency cycles (no problem with that).
>
> That is why I'd like to propose to introduce SDEPEND, with the
> following, simple, semantics:
> dependencies listed in SDEPEND are not required at build time nor
> strictly at runtime and they just enable more features in the
> installed application. There can be "use?" literals and by default,
> PMS should not pull them in in the dependencies calculation if not
> specifically asked (through argument or configuration file or else --
> like it happens with binpkgs and --with-bdeps).
>
> A bunch of advantages over GLEP 62:
> - Simplicity (really, as in KISS). SDEPENDs are easier to understand
> and deal with, both at PMS (code) and user levels. They are also
> straightforward to use in ebuilds (dev) and through emerge (user). [1]
> - The USE flags meaning doesn't really get "stretched" introducing
> obscure, unknown and dangerous possible side effects when deployed in
> the real(tm) world. I understand that there is some level of risk with
> SDEPENDs as well, but we've seen them already in Exherbo and they seem
> to work fine there (I've been told this).
> - Doesn't preclude the implementation of GLEP 62 anyway. SDEPENDs are
> just "suggested" dependencies after all!
> - No need to introduce funky cache invalidation logic for PMS
> aggressively using caching at several layers of their stack and that
> guarantee a consistent depgraph for the installed pkgs repository as
> well [2].
> - Fixes the "dissociative identity disorder" of PDEPEND ;-).
>
> Disadvantages:
> - If SDEPEND contains USE flags, these are written in stone and cannot
> be changed without a rebuild. This is generally fine for source
> packages, a bit less for binpkgs, but not really a big deal IMO.
> - Not as "elastic" as GLEP 62 USE flags, but neither *DEPENDs are
> - mgorny will hate me (eheheheh)
>
> Discuss.
>
> [1] It took me more than 5 minutes to understand how GLEP 62 works in
> practice and this is not really good to me, for a simple feature like
> this.
> [2] From GLEP 62 page: "and it is not strictly required that a package
> manager must ensure that the dependency graph is still consistent
> afterwards".

Is it fifth thread on the same topic already?

--
Best regards,
Michał Górny
 
Old 09-02-2012, 03:23 PM
Michał Górny
 
Default EAPI 5+: split PDEPEND introducing SDEPEND

On Sun, 2 Sep 2012 17:09:22 +0200
Fabio Erculiani <lxnay@gentoo.org> wrote:

> On Sun, Sep 2, 2012 at 4:57 PM, hasufell <hasufell@gentoo.org> wrote:
> >
> >
> > Why not introduce a global useflag such as "suggested-deps" which
> > complies with GLEP 62 meaning it will be in IUSE_RUNTIME.
> >
>
> How do you manage to fix the PDEPEND "identity disorder" problem then?
> Teaching devs to move to GLEP 62 is much harder than just telling them
> to move dep strings to more appropriate locations.

Much harder? So, devs today don't know how USE flags work? Or do you
implying that devs should know bare technical details of package
manager implementation? Or is it just an-ass argument to support
an ass-thesis?

> Moreover, your solution just makes the USE flags abuse situation
> worse: there are packages that use USE flags just to include extra,
> optional packages in the dependencies... See USE=bluetooth in
> net-misc/networkmanager for example (this is what I mean with USE
> flags abuse, actually).

No, it fixes it. It enables those packages to use the same solution,
fixing its downsides.

> I'm not saying that SDEPEND is the best one-size-fits-all solution but
> you may agree that's the simplest and most effective one.

pkg_postinst() is simpler. USE flags are simple and very effective, yet
incorrect.

An effective SDEPEND implementation is definitely nowhere close
to simple. Nor is presenting those dependencies to users.

--
Best regards,
Michał Górny
 

Thread Tools




All times are GMT. The time now is 11:26 AM.

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