[gentoo-dev] Policy-level discussion for minimum versions on dependencies

[gentoo-dev] Policy-level discussion for minimum versions on dependencies

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi all...  Mozilla had a bug recently (
http://bugs.gentoo.org/show_bug.cgi?id=489838 ) that I think has much
wider implications for all packages, and I would like to discuss how
to best address this.

The synopsis of the situation is that the latest firefox ebuild now
depends on icu, specifically icu-50.1 or above.  When this version of
firefox was added to the tree, the lowest version of icu in the tree
was icu-51.0 -- in fact, icu-48 through icu-50 were dropped from the
tree about 2 months prior to the new firefox being added.

The bug that was filed, is that a user didn't do a full emerge -uDN
@world prior to emerging (upgrading?) firefox, and they had icu-49
already installed.  Because the firefox dep didn't have a minimum
version, portage didn't see upgrading icu as a requirement before
firefox emerged.

I fully agree with the user and other commenters on the bug, that
after --sync'ing a user should be able to 'emerge [-u] firefox' and
all necessary dependency updates would be applied.

However, it's been a long-standing general practise that if there are
no deps in the tree older than what is necessary for a package, that
package doesn't need to have a minimum version on the dependency atom.
 As such, issues similar to this are probably lying in wait all other
the place in the tree.

To mitigate this, i see three possibilities:

1 - make it clear in documentation for end users that they need to
emerge -uDN @world after a --sync, otherwise they may see breakage and
if they do it's not a bug when an emerge -uDN @world fixes it.  IMO
this is not a desirable solution but it best matches what is
unofficially required now.

2 - make a policy for developers that they need to add minimum
versions on dependency atoms so that their package will trigger
dependency updates, for all dependencies that have in the last year
(**) had a version in the tree older than what the package needs.
This is the most "correct" solution, but requires all devs to do the work.

3 - change portage behaviour s.t. somehow when resolving dependencies
it does not consider installed atoms that are missing from the tree to
be valid at satisfying a dependency of a package.  This would resolve
the issue without dev's as a whole needing to do anything different,
but would also have unforseen consequences since this is a major
behavioural change for portage's dependency resolution.

Thoughts?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlJ6XSIACgkQ2ugaI38ACPAWtgEAsiXy5LmYriPMeRanleI7fqNK
faU2TwOpvykeYfEwpqQA/AirKpkPwpSp6tGau1PPjeOIGUuz6dZgnL8KkZ/J9JEa
=VUYT
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 1464 bytes --]

On 7 November 2013 04:15, Ian Stakenvicius <axs@gentoo.org> wrote:

>
> The bug that was filed, is that a user didn't do a full emerge -uDN
> @world prior to emerging (upgrading?) firefox, and they had icu-49
> already installed.  Because the firefox dep didn't have a minimum
> version, portage didn't see upgrading icu as a requirement before
> firefox emerged.
>

Theres another scenario not listed here which can still happen:

The end user has a copy of icu-49.ebuild somewhere in their portage layout
still.

Either this is due to a published overlay containing it, or them locally
maintaining their own private overlay.

The "update world" thing *may* still work in such a circumstance, but you'd
have to change the policy to say "Update to a something that is in ::gentoo
before merging packages from ::gentoo", which is getting a bit logically
messy.

Even then, it may not be apparent that there is a problem, for instance, if
they have the overlay in place, *AND* they've locally masked newer versions
of icu, for some reason ( perhaps they have 3rd party software they're
locally maintaining that requires an older version of icu ).

Here, the *only* sane approach is for firefox to declare it needs a certain
version of icu as a minimum, regardless of what is, and what isn't visible
in tree, so that the end user at very least gets told "firefox needs this",
and its then their responsibility to sort out the problem if they've caused
one.

-- 
Kent

[-- Attachment #2: Type: text/html, Size: 2074 bytes --]

Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 06/11/13 10:26 AM, Kent Fredric wrote:
> 
> On 7 November 2013 04:15, Ian Stakenvicius <axs@gentoo.org 
> <mailto:axs@gentoo.org>> wrote:
> 
> 
> The bug that was filed, is that a user didn't do a full emerge
> -uDN @world prior to emerging (upgrading?) firefox, and they had
> icu-49 already installed.  Because the firefox dep didn't have a
> minimum version, portage didn't see upgrading icu as a requirement
> before firefox emerged.
> 
> 
> Theres another scenario not listed here which can still happen:
> 
> The end user has a copy of icu-49.ebuild somewhere in their
> portage layout still.
> 
> Either this is due to a published overlay containing it, or them
> locally maintaining their own private overlay.

Yes, however there's no way to keep overlays (especially unofficial
ones) from messing with what portage does, and IMO there shouldn't be
- -- I think we've made it clear that conflicts arising between in-tree
and overlay packages (whether they be deps or not) are for the
end-users to resolve.

That said, I agree:

> Here, the *only* sane approach is for firefox to declare it needs
> a certain version of icu as a minimum, regardless of what is, and
> what isn't visible in tree, so that the end user at very least gets
> told "firefox needs this", and its then their responsibility to
> sort out the problem if they've caused one.

Option #2 to me also seems to be the way to go..

If we can reach a consensus here, adding some text to the devmanual or
developer guide should suffice, yes?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlJ6YykACgkQ2ugaI38ACPApYgD/fx1QrWxlBWOxJX5lsIqS1DVp
E3ClB9ketAWsPt7LmqMBAI1mVm/td9BLyfSGSP+Qi43kTzR+TISwecvPmqnvsKYE
=W3Ul
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies

[Alexis Ballier]

On Wed, 2013-11-06 at 10:15 -0500, Ian Stakenvicius wrote:
> However, it's been a long-standing general practise that if there are
> no deps in the tree older than what is necessary for a package, that
> package doesn't need to have a minimum version on the dependency atom.
>  As such, issues similar to this are probably lying in wait all other
> the place in the tree.

this is a common misconception: ebuilds must have min. deps matching
their requirements (exactly because of this problem)

it can be fixed on the user side by 'emerge -uDN world' meanwhile but
this doesn't mean the ebuild doesn't have a bug, even if minor

Alexis.

Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 1073 bytes --]

On 11/6/13 7:15 AM, Ian Stakenvicius wrote:
> The synopsis of the situation is that the latest firefox ebuild now
> depends on icu, specifically icu-50.1 or above.  When this version of
> firefox was added to the tree, the lowest version of icu in the tree
> was icu-51.0 -- in fact, icu-48 through icu-50 were dropped from the
> tree about 2 months prior to the new firefox being added.
> 
> The bug that was filed, is that a user didn't do a full emerge -uDN
> @world prior to emerging (upgrading?) firefox, and they had icu-49
> already installed.  Because the firefox dep didn't have a minimum
> version, portage didn't see upgrading icu as a requirement before
> firefox emerged.

I've seen things like that happening.

I wouldn't really create yet another policy (it doesn't make things
happen). I'd leave it up to the maintainer: it'd be fine to declare it
not a bug, and it'd also be fine to fix.

I'm generally leaning toward fixing and adding the minimum version to
deps. Helps the users, and doesn't really hurt maintainability.

Paweł


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies

[Alan McKinnon]

On 06/11/2013 17:26, Kent Fredric wrote:
> 
> On 7 November 2013 04:15, Ian Stakenvicius <axs@gentoo.org
> <mailto:axs@gentoo.org>> wrote:
> 
> 
>     The bug that was filed, is that a user didn't do a full emerge -uDN
>     @world prior to emerging (upgrading?) firefox, and they had icu-49
>     already installed.  Because the firefox dep didn't have a minimum
>     version, portage didn't see upgrading icu as a requirement before
>     firefox emerged.
> 
> 
> Theres another scenario not listed here which can still happen:
> 
> The end user has a copy of icu-49.ebuild somewhere in their portage
> layout still.
> 
> Either this is due to a published overlay containing it, or them locally
> maintaining their own private overlay.
> 
> The "update world" thing *may* still work in such a circumstance, but
> you'd have to change the policy to say "Update to a something that is in
> ::gentoo before merging packages from ::gentoo", which is getting a bit
> logically messy.
> 
> Even then, it may not be apparent that there is a problem, for instance,
> if they have the overlay in place, *AND* they've locally masked newer
> versions of icu, for some reason ( perhaps they have 3rd party software
> they're locally maintaining that requires an older version of icu ).
> 
> Here, the *only* sane approach is for firefox to declare it needs a
> certain version of icu as a minimum, regardless of what is, and what
> isn't visible in tree, so that the end user at very least gets told
> "firefox needs this", and its then their responsibility to sort out the
> problem if they've caused one.

I agree with this sentiment. It's always been my view that the needs of
a package are driven by the package itself, not by the tree.

Rationale: A package will build and run as long as it's own requirements
are met regardless of what the tree states.

We have layman overlays and user's own overlays. Whilst these are not
100% supported by Gentoo they are not banned either. They are also not
"barely tolerated", it's more a case of overlays are not a problem and
users are welcome to use them as long as they don't conflict with or
break the tree for that user.

This needn't be onerous. Presumably ebuild maintainers read the README
and Changelog, these often state the versions of deps the package
supports. Take that information and put it in the ebuild. Maintainers
are under no obligation to provide the absolute minimum version of a
dep, only at least one that will work. If the user decides to make other
versions available to his system by whatever means, then portage can
deal with it by and large transparently.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies

[yac]

[-- Attachment #1: Type: text/plain, Size: 1373 bytes --]

On Wed, 06 Nov 2013 16:48:54 +0100
Alexis Ballier <aballier@gentoo.org> wrote:

> On Wed, 2013-11-06 at 10:15 -0500, Ian Stakenvicius wrote:
> > However, it's been a long-standing general practise that if there
> > are no deps in the tree older than what is necessary for a package,
> > that package doesn't need to have a minimum version on the
> > dependency atom. As such, issues similar to this are probably lying
> > in wait all other the place in the tree.
> 
> this is a common misconception: ebuilds must have min. deps matching
> their requirements (exactly because of this problem)
> 
> it can be fixed on the user side by 'emerge -uDN world' meanwhile but
> this doesn't mean the ebuild doesn't have a bug, even if minor
> 
> Alexis.

When I started contributing via sunrise, I've been
adding the minimal versions of dependencies as declared by upstream
but I met with very strict enforcement of the policy to not
specify minimal version if all the ones in current tree satisfies.

Is it documented somewhere or is it just unwritten consensus?

What I see is only Ebuild Policy [1e] which doesn't deal with this.

.. [1e] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1

---
Jan Matějka        | Gentoo Developer
https://gentoo.org | Gentoo Linux
GPG: A33E F5BC A9F6 DAFD 2021  6FB6 3EBF D45B EEB6 CA8B

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 06/11/13 12:56 PM, yac wrote:
> On Wed, 06 Nov 2013 16:48:54 +0100 Alexis Ballier
> <aballier@gentoo.org> wrote:
> 
>> On Wed, 2013-11-06 at 10:15 -0500, Ian Stakenvicius wrote:
>>> However, it's been a long-standing general practise that if
>>> there are no deps in the tree older than what is necessary for
>>> a package, that package doesn't need to have a minimum version
>>> on the dependency atom. As such, issues similar to this are
>>> probably lying in wait all other the place in the tree.
>> 
>> this is a common misconception: ebuilds must have min. deps
>> matching their requirements (exactly because of this problem)
>> 
>> it can be fixed on the user side by 'emerge -uDN world' meanwhile
>> but this doesn't mean the ebuild doesn't have a bug, even if
>> minor
>> 
>> Alexis.
> 
> When I started contributing via sunrise, I've been adding the
> minimal versions of dependencies as declared by upstream but I met
> with very strict enforcement of the policy to not specify minimal
> version if all the ones in current tree satisfies.
> 
> Is it documented somewhere or is it just unwritten consensus?
> 
> What I see is only Ebuild Policy [1e] which doesn't deal with
> this.
> 
> .. [1e]
> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1
>
> 
I searched as well, and couldn't find anything documented one way or
the other, either.  I concluded that it's unwritten consensus.

That's the main reason I wanted to start this discussion -- to
effectively start documenting it and get dev's all on the same page.
To be honest I think it should be policy or at least a written-down
guideline, that dev's should do this within reason -- if an
older-than-minimum version of something has been in the tree within
the past year.  Gone for more than a year should be safe, I expect.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlJ6hKMACgkQ2ugaI38ACPB8RwD/aYX0JSAeb1xsWVejdf65jPVP
QSIYlCp5v/gdYw88kdMA/22f9UHoBep+iwJq5uYeHLmJFMRYRELnihBhNJkzM5rE
=3xf4
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies

[Mike Gilbert]

On Wed, Nov 6, 2013 at 1:04 PM, Ian Stakenvicius <axs@gentoo.org> wrote:
> On 06/11/13 12:56 PM, yac wrote:
>> On Wed, 06 Nov 2013 16:48:54 +0100 Alexis Ballier
>> <aballier@gentoo.org> wrote:
>>
>>> On Wed, 2013-11-06 at 10:15 -0500, Ian Stakenvicius wrote:
>>>> However, it's been a long-standing general practise that if
>>>> there are no deps in the tree older than what is necessary for
>>>> a package, that package doesn't need to have a minimum version
>>>> on the dependency atom. As such, issues similar to this are
>>>> probably lying in wait all other the place in the tree.
>>>
>>> this is a common misconception: ebuilds must have min. deps
>>> matching their requirements (exactly because of this problem)
>>>
>>> it can be fixed on the user side by 'emerge -uDN world' meanwhile
>>> but this doesn't mean the ebuild doesn't have a bug, even if
>>> minor
>>>
>>> Alexis.
>>
>> When I started contributing via sunrise, I've been adding the
>> minimal versions of dependencies as declared by upstream but I met
>> with very strict enforcement of the policy to not specify minimal
>> version if all the ones in current tree satisfies.
>>
>> Is it documented somewhere or is it just unwritten consensus?
>>
>> What I see is only Ebuild Policy [1e] which doesn't deal with
>> this.
>>
>> .. [1e]
>> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1
>>
>>
> I searched as well, and couldn't find anything documented one way or
> the other, either.  I concluded that it's unwritten consensus.
>
> That's the main reason I wanted to start this discussion -- to
> effectively start documenting it and get dev's all on the same page.
> To be honest I think it should be policy or at least a written-down
> guideline, that dev's should do this within reason -- if an
> older-than-minimum version of something has been in the tree within
> the past year.  Gone for more than a year should be safe, I expect.
>

I don't think a time limit is necessary here. If there is an
identified incompatibility, we should update DEPEND.

Note that I do not expect devs to go out of their way to test for the
oldest supported version of a dependency; they just shouldn't close
bugs as INVALID of someone else has done the work.

Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies

[Rich Freeman]

On Wed, Nov 6, 2013 at 11:15 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> I agree with this sentiment. It's always been my view that the needs of
> a package are driven by the package itself, not by the tree.
>
> Rationale: A package will build and run as long as it's own requirements
> are met regardless of what the tree states.
>

++, and to all that follows.

I wouldn't go hunting down and bugging devs for every atom that
doesn't specify a minimum version - this stuff isn't always easy to
find.  However, if somebody offers a minimum version I'd consider it a
valid bug.

I think giving the resolver as much information as possible will only
tend to reduce issues, especially in a distro like Gentoo where doing
things differently is the norm.

Rich

Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies

[yac]

[-- Attachment #1: Type: text/plain, Size: 2638 bytes --]

On Wed, 6 Nov 2013 13:22:13 -0500
Mike Gilbert <floppym@gentoo.org> wrote:

> On Wed, Nov 6, 2013 at 1:04 PM, Ian Stakenvicius <axs@gentoo.org>
> wrote:
> > On 06/11/13 12:56 PM, yac wrote:
> >> On Wed, 06 Nov 2013 16:48:54 +0100 Alexis Ballier
> >> <aballier@gentoo.org> wrote:
> >>
> >>> On Wed, 2013-11-06 at 10:15 -0500, Ian Stakenvicius wrote:
> >>>> However, it's been a long-standing general practise that if
> >>>> there are no deps in the tree older than what is necessary for
> >>>> a package, that package doesn't need to have a minimum version
> >>>> on the dependency atom. As such, issues similar to this are
> >>>> probably lying in wait all other the place in the tree.
> >>>
> >>> this is a common misconception: ebuilds must have min. deps
> >>> matching their requirements (exactly because of this problem)
> >>>
> >>> it can be fixed on the user side by 'emerge -uDN world' meanwhile
> >>> but this doesn't mean the ebuild doesn't have a bug, even if
> >>> minor
> >>>
> >>> Alexis.
> >>
> >> When I started contributing via sunrise, I've been adding the
> >> minimal versions of dependencies as declared by upstream but I met
> >> with very strict enforcement of the policy to not specify minimal
> >> version if all the ones in current tree satisfies.
> >>
> >> Is it documented somewhere or is it just unwritten consensus?
> >>
> >> What I see is only Ebuild Policy [1e] which doesn't deal with
> >> this.
> >>
> >> .. [1e]
> >> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1
> >>
> >>
> > I searched as well, and couldn't find anything documented one way or
> > the other, either.  I concluded that it's unwritten consensus.
> >
> > That's the main reason I wanted to start this discussion -- to
> > effectively start documenting it and get dev's all on the same page.
> > To be honest I think it should be policy or at least a written-down
> > guideline, that dev's should do this within reason -- if an
> > older-than-minimum version of something has been in the tree within
> > the past year.  Gone for more than a year should be safe, I expect.
> >
> 
> I don't think a time limit is necessary here. If there is an
> identified incompatibility, we should update DEPEND.
> 
> Note that I do not expect devs to go out of their way to test for the
> oldest supported version of a dependency; they just shouldn't close
> bugs as INVALID of someone else has done the work.
> 

+1 very much.

---
Jan Matějka        | Gentoo Developer
https://gentoo.org | Gentoo Linux
GPG: A33E F5BC A9F6 DAFD 2021  6FB6 3EBF D45B EEB6 CA8B

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

[gentoo-dev] Re: Policy-level discussion for minimum versions on dependencies

[Duncan]

Rich Freeman posted on Wed, 06 Nov 2013 13:28:13 -0500 as excerpted:

> I think giving the resolver as much information as possible will only
> tend to reduce issues, especially in a distro like Gentoo where doing
> things differently is the norm.

++ to both you and Alan McK's thoughts.

Meanwhile, I like that last subsentence.  Maybe time for a new Gentoo 
slogan?

Gentoo: Where doing things differently is the norm!

Hey, Apple can "think different", we can "DO different!" =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies

[Alexis Ballier]

On Wed, 2013-11-06 at 13:04 -0500, Ian Stakenvicius wrote:
> On 06/11/13 12:56 PM, yac wrote:
> > On Wed, 06 Nov 2013 16:48:54 +0100 Alexis Ballier
> > <aballier@gentoo.org> wrote:
> > 
> >> On Wed, 2013-11-06 at 10:15 -0500, Ian Stakenvicius wrote:
> >>> However, it's been a long-standing general practise that if
> >>> there are no deps in the tree older than what is necessary for
> >>> a package, that package doesn't need to have a minimum version
> >>> on the dependency atom. As such, issues similar to this are
> >>> probably lying in wait all other the place in the tree.
> >> 
> >> this is a common misconception: ebuilds must have min. deps
> >> matching their requirements (exactly because of this problem)
> >> 
> >> it can be fixed on the user side by 'emerge -uDN world' meanwhile
> >> but this doesn't mean the ebuild doesn't have a bug, even if
> >> minor
> >> 
> >> Alexis.
> > 
> > When I started contributing via sunrise, I've been adding the
> > minimal versions of dependencies as declared by upstream but I met
> > with very strict enforcement of the policy to not specify minimal
> > version if all the ones in current tree satisfies.
> > 
> > Is it documented somewhere or is it just unwritten consensus?
> > 
> > What I see is only Ebuild Policy [1e] which doesn't deal with
> > this.
> > 
> > .. [1e]
> > http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1
> >
> > 
> I searched as well, and couldn't find anything documented one way or
> the other, either.  I concluded that it's unwritten consensus.
> 
> That's the main reason I wanted to start this discussion -- to
> effectively start documenting it and get dev's all on the same page.
> To be honest I think it should be policy or at least a written-down
> guideline, that dev's should do this within reason -- if an
> older-than-minimum version of something has been in the tree within
> the past year.  Gone for more than a year should be safe, I expect.

its kind of common sense IMHO but if you want a policy, then go for
it :)

there shouldn't be any time limit; portage doesnt do -uDN by default and
people want this because of the "if it ain't broken don't fix it" motto.
with prod servers you want to update portage for EAPI stuff, get
security fixes, but not much more; even an "up to date" box can have 5
years gone packages.

in short: if a package requires version X then the ebuild should require
version X; it can be forgotten but it's a bug.

Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies

[Peter Stuge]

Alexis Ballier wrote:
> its kind of common sense IMHO

Unfortunately what makes sense to people is never common. :\


> there shouldn't be any time limit
..
> in short: if a package requires version X then the ebuild should
> require version X; it can be forgotten but it's a bug.

+1


//Peter

Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies

[Rémi Cardona]

Le jeudi 07 novembre 2013 à 10:44 +0100, Alexis Ballier a écrit :
> in short: if a package requires version X then the ebuild should require
> version X; it can be forgotten but it's a bug.

That _is_ our policy. Ebuilds should - at the very least - mirror what
upstream's build script requires.

So, count my +1 there.

Rémi

Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 862 bytes --]

On Wed, Nov 06, 2013 at 01:28:13PM -0500, Rich Freeman wrote:
> On Wed, Nov 6, 2013 at 11:15 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> > I agree with this sentiment. It's always been my view that the needs of
> > a package are driven by the package itself, not by the tree.
> >
> > Rationale: A package will build and run as long as it's own requirements
> > are met regardless of what the tree states.
> >
> 
> ++, and to all that follows.
> 
> I wouldn't go hunting down and bugging devs for every atom that
> doesn't specify a minimum version - this stuff isn't always easy to
> find.  However, if somebody offers a minimum version I'd consider it a
> valid bug.

As a maintainer, I start by checking the documentation for the
software I was packaging and making the dependencies match the version
requirements there.

William

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies

[Ben de Groot]

On 8 November 2013 08:55, Rémi Cardona <remi@gentoo.org> wrote:
> Le jeudi 07 novembre 2013 à 10:44 +0100, Alexis Ballier a écrit :
>> in short: if a package requires version X then the ebuild should require
>> version X; it can be forgotten but it's a bug.
>
> That _is_ our policy.

Since this thread was deemed necessary, apparently it's not.
Or at least not clearly stated.

> Ebuilds should - at the very least - mirror what
> upstream's build script requires.

And they do. Strictly spoken, we do not support ebuilds / versions
that are not (or no longer) in the tree. If the user chooses to use
ebuilds / versions we don't support, they are on their own.

That said, we can do it as a courtesy to users, when it is brought
to our attention. But it's more of an "enhancement" than a bug,
in my opinion.

-- 
Cheers,

Ben | yngwin
Gentoo developer

Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 961 bytes --]

Am Samstag, 9. November 2013, 02:19:32 schrieb Ben de Groot:
> On 8 November 2013 08:55, Rémi Cardona <remi@gentoo.org> wrote:
> > Le jeudi 07 novembre 2013 à 10:44 +0100, Alexis Ballier a écrit :
> >> in short: if a package requires version X then the ebuild should require
> >> version X; it can be forgotten but it's a bug.
> > 
> > That _is_ our policy.
> 
> Since this thread was deemed necessary, apparently it's not.
> Or at least not clearly stated.
> 

It was not clear, and we should officially clarify it somewhere in the 
documentation. 

(I also learnt as a recruit that "versionless dependency is fine if all 
versions in the portage tree fulfill it". As a consequence I have been 
regularly dropping version dependencies from ebuilds for simplification if the 
excluded versions were long gone from the tree.)

-- 
Andreas K. Huettel
Gentoo Linux developer (council, kde)
dilfridge@gentoo.org
http://www.akhuettel.de/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies

[Matt Turner]

On Sat, Nov 9, 2013 at 4:28 AM, Andreas K. Huettel <dilfridge@gentoo.org> wrote:
> Am Samstag, 9. November 2013, 02:19:32 schrieb Ben de Groot:
>> On 8 November 2013 08:55, Rémi Cardona <remi@gentoo.org> wrote:
>> > Le jeudi 07 novembre 2013 à 10:44 +0100, Alexis Ballier a écrit :
>> >> in short: if a package requires version X then the ebuild should require
>> >> version X; it can be forgotten but it's a bug.
>> >
>> > That _is_ our policy.
>>
>> Since this thread was deemed necessary, apparently it's not.
>> Or at least not clearly stated.
>>
>
> It was not clear, and we should officially clarify it somewhere in the
> documentation.
>
> (I also learnt as a recruit that "versionless dependency is fine if all
> versions in the portage tree fulfill it". As a consequence I have been
> regularly dropping version dependencies from ebuilds for simplification if the
> excluded versions were long gone from the tree.)

For what gain? It seems to only allow breakage when updating old systems.

Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 774 bytes --]

Am Samstag, 9. November 2013, 18:02:50 schrieb Matt Turner:
>
> > (I also learnt as a recruit that "versionless dependency is fine if all
> > versions in the portage tree fulfill it". As a consequence I have been
> > regularly dropping version dependencies from ebuilds for simplification
> > if the excluded versions were long gone from the tree.)
> 
> For what gain? It seems to only allow breakage when updating old systems.

No loss (since systems not upgraded that long were not considered supported 
anyway), arguably small gain of more maintainable and readable dependency 
lists. I just learned "that's how it is done" when I started here.

-- 
Andreas K. Huettel
Gentoo Linux developer (council, kde)
dilfridge@gentoo.org
http://www.akhuettel.de/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies

[Thomas Kahle]

[-- Attachment #1: Type: text/plain, Size: 1430 bytes --]

On 11/09/2013 06:02 PM, Matt Turner wrote:
> On Sat, Nov 9, 2013 at 4:28 AM, Andreas K. Huettel <dilfridge@gentoo.org> wrote:
>> Am Samstag, 9. November 2013, 02:19:32 schrieb Ben de Groot:
>>> On 8 November 2013 08:55, Rémi Cardona <remi@gentoo.org> wrote:
>>>> Le jeudi 07 novembre 2013 à 10:44 +0100, Alexis Ballier a écrit :
>>>>> in short: if a package requires version X then the ebuild should require
>>>>> version X; it can be forgotten but it's a bug.
>>>>
>>>> That _is_ our policy.
>>>
>>> Since this thread was deemed necessary, apparently it's not.
>>> Or at least not clearly stated.
>>>
>>
>> It was not clear, and we should officially clarify it somewhere in the
>> documentation.
>>
>> (I also learnt as a recruit that "versionless dependency is fine if all
>> versions in the portage tree fulfill it". As a consequence I have been
>> regularly dropping version dependencies from ebuilds for simplification if the
>> excluded versions were long gone from the tree.)
> 
> For what gain? It seems to only allow breakage when updating old systems

I've also dropped minimum version requirements in the past.  I
wonder if there a performance hit?  If every package in the tree
specified min versions of all its dependencies, would resolution
of emerge -avuDN world take longer?  (It does take a couple of
minutes already on my aging laptop...)

Cheers,
Thomas


-- 
Thomas Kahle


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]