Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies
On 11/09/2013 06:02 PM, Matt Turner wrote: On Sat, Nov 9, 2013 at 4:28 AM, Andreas K. Huettel dilfri...@gentoo.org wrote: Am Samstag, 9. November 2013, 02:19:32 schrieb Ben de Groot: On 8 November 2013 08:55, Rémi Cardona r...@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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies
Am Samstag, 9. November 2013, 02:19:32 schrieb Ben de Groot: On 8 November 2013 08:55, Rémi Cardona r...@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) dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies
On Sat, Nov 9, 2013 at 4:28 AM, Andreas K. Huettel dilfri...@gentoo.org wrote: Am Samstag, 9. November 2013, 02:19:32 schrieb Ben de Groot: On 8 November 2013 08:55, Rémi Cardona r...@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
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) dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies
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.mckin...@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 signature.asc Description: Digital signature
Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies
On 8 November 2013 08:55, Rémi Cardona r...@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
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 aball...@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=2chap=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
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
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
On 7 November 2013 04:15, Ian Stakenvicius a...@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
Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/11/13 10:26 AM, Kent Fredric wrote: On 7 November 2013 04:15, Ian Stakenvicius a...@gentoo.org mailto:a...@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
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
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ł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies
On 06/11/2013 17:26, Kent Fredric wrote: On 7 November 2013 04:15, Ian Stakenvicius a...@gentoo.org mailto:a...@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.mckin...@gmail.com
Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies
On Wed, 06 Nov 2013 16:48:54 +0100 Alexis Ballier aball...@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=2chap=1 --- Jan Matějka| Gentoo Developer https://gentoo.org | Gentoo Linux GPG: A33E F5BC A9F6 DAFD 2021 6FB6 3EBF D45B EEB6 CA8B signature.asc Description: PGP signature
Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies
-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 aball...@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=2chap=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
On Wed, Nov 6, 2013 at 1:04 PM, Ian Stakenvicius a...@gentoo.org wrote: On 06/11/13 12:56 PM, yac wrote: On Wed, 06 Nov 2013 16:48:54 +0100 Alexis Ballier aball...@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=2chap=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
On Wed, Nov 6, 2013 at 11:15 AM, Alan McKinnon alan.mckin...@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
On Wed, 6 Nov 2013 13:22:13 -0500 Mike Gilbert flop...@gentoo.org wrote: On Wed, Nov 6, 2013 at 1:04 PM, Ian Stakenvicius a...@gentoo.org wrote: On 06/11/13 12:56 PM, yac wrote: On Wed, 06 Nov 2013 16:48:54 +0100 Alexis Ballier aball...@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=2chap=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 signature.asc Description: PGP signature
