Re: [gentoo-dev] RFC: Reviving GLEP33
On Mon, Aug 02, 2010 at 11:55:07PM +0200, Matti Bickel wrote: > On 08/02/2010 10:15 PM, Ciaran McCreesh wrote: > > Aren't you really after per-package eclasses, not elibs? > > Yes. I don't care whether the snippets may affect metadata. They already > don't (at one time they did, but we got warned that that's illegal - > that's why php-5.3 ebuilds have their metadata folded back into them). > > >> Instead of all the backwards-compatibility issues the GLEP deals with, > >> we could just sneak the implementation into EAPI4 and be done with it. > > > > No, you can't make global scope changes just in an EAPI without > > screwing up user systems. You have to do the whole "wait several years" > > thing for them. While it's been repeated many, many time, this statement is provably false. What _is_ true is that you cannot have new global scope functionality that influences/sets EAPI. That is _accurate_ truth of the matter. If a PM encounters an EAPI it doesn't understand/support, by definition the metadata it tried generating is not usable- the PM doesn't support that new EAPI thus it has zero clue how to generate/store metadata appropriately for that EAPI. Note that since policy forbids EAPI being set in eclasses _anyways_, there isn't a conflict here despite ciaran's claims. If an EAPI adds a new global function that cannot set/influence EAPI, PM's that don't support that EAPI will spit complaints about 'missing command' during sourcing- however the PM will still see the EAPI value is one it knows it doesn't support, and act accordingly. Basically, the only real issue here is that PMs invalidly output stdout/stderr for EAPIs they don't support- this gives the perception that there is an issue, when in reality it's just the PM being slightly user unfriendly. > Bad. So I guess it's back to ferring's "use a new directory not readable > by old PMs" idea. GLEP55++, but having to wait several months for that > and GLEP33 *on top* is not very motivation for me. The reason for a new directory was to enforce a new structuring that was more friendly to changelogs and manifests- due to ECLASSDIR being documented in PMS (and annoyingly eclass-manpagers being the sole consumer of it) adding a new eclasses directory should require a EAPI bump. As for per package eclasses, I'd personally require accessing the package eclass being done via a new inherit function- this avoids some annoying gotchas. That said, I don't see a reason right now that it couldn't be added into an EAPI, per the reasons I laid out earlier in this email. ~brian pgpIa4DAqHM6U.pgp Description: PGP signature
Re: [gentoo-dev] Package version in case of upstream patches from stable branch of development
On Wed, Aug 04, 2010 at 05:05:11PM +0400, Peter Volkov wrote: > В Срд, 04/08/2010 в 09:42 +, Jorge Manuel B. S. Vicetto пишет: > > There are already a few bugs that can be attributed to this. > > Ok, let's say that this depends on upstream. And for Gentoo this means > that the decision how to set version for the package depends on > maintainer. Lot's of packages do not have dedicated release tests > upstream (even build tests) and for this packages I don't see difference > between stable branch and release. In such case our version just > indicates that our package is base on tarbal of that version and nothing > more. The core thing people are ignoring in this discussion is that when you do the following in your python consuming code- python -c 'import sys.version;print sys.version_info' (2, 6, 5, 'final', 0) You know what version of python you're running- not even version as much as what the api is. Code relies on this. When a 2.6.5 is actually a 2.6.6rc* in API but still exporting sys.version == 2.6.5, you screw up consuming code's ability to detect the version and adjust itself accordingly. That right there is a serious problem. Combine that with gentoo's longstanding history of patching things to make it work, but not going insanely beyond that and you've got a pretty strong qa/policy conflict. If you doubt this history, why not look through the python projects previous patch- http://overlays.gentoo.org/proj/python/browser/patches The point people miss in this discussion is that python isn't some standalone pkg- a lot of code consume's it's api's. As such silently pulling in api changes that will land in 2.6.6 starts becoming _extremely_ problematic, and it's contrary to longstanding gentoo maintenance. > > This is unfortunately the main issue here. You may work on a specific > > package on Gentoo, but when that package is essential for the system > > use / stability, it stops being just "your" package. This latest > > example has lead users to a point where their PM stopped working. > > Breaking the PM is not a small "oops" > > That's completely different topic... I'm not talking about stability at > all. Of course, python is special package and should be treated/tested > by maintainers as such! Probably for such core packages ~arch is not > enough and we need different process... But that a different topic. > > Bug I mentioned pretends that we have policy how to set version for > packages that use backported upstream patches. My point is that there is > no such policy and line between _p or -rN is very fuzzy to set such > policy. Thus bug itself is INVALID... This is essentially lawyering; it's not bad until someone creates a rule saying it's bad, even if historical precedent proceeds it. Trying to legislate every possible scenario of common sense/sane maintenance practices leads to insanity. Godel had something to say about this ;) Gentoo generally speaking, is fixed versions of upstream released. We do have integration done, but we don't monkey patch the hell out of their releases- notice also I said 'fixed'. Trying to make 2.6.5 a 2.6.6 isn't exactly "fixing it"- yes there are fixes that should be pulled from the maintenance branch, but there is a very real difference between selective cherry picking and full scale importation as was occuring. ~harring pgpa0eS2sKdA8.pgp Description: PGP signature
[gentoo-dev] sys-devel/gettext and implicit vcs packages (cvs/git)
the gettext package and its implicit vcs has been a problem for us for time immemorial (one of the first documented instances is Bug 55607 dated Jun 2004). at the time, we really had no way of handling this cleanly. but with USE deps now, i think we address this somewhat sanely. background: the gettext package supports older versions of itself while minimizing disk space by storing the deployable files in a vcs archive. this is only used at runtime if you run `autopoint`, and that is only used during development where the bundled gettext files in a package need to be recreated. in the past, it only used cvs, but now it supports both cvs and git (which are detected when gettext is emerged). in the past, we just forced the smallish random packages that actually ran autotools to depend on cvs themselves. what i'm proposing now is that we add a local USE flag (Nick proposed "autopoint") to sys-devel/gettext. something like: RDEPEND="autopoint? ( git? ( dev-vcs/git ) !git? ( cvs? ( dev-vcs/cvs ) ) !cvs? ( dev-vcs/git ) )" idea is that we want to prefer git over cvs. now other packages can DEPEND on sys-devel/gettext[autopoint]. perhaps even extend autotools.eclass with a variable to indicate people are going to be using eautopoint ... any counter proposals/etc... ? -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] net-proxy/squid needs your love
On 08/04/2010 08:34 PM, Markos Chandras wrote: > On Wed, Aug 04, 2010 at 07:12:18PM +0300, Petteri Räty wrote: >> On 08/04/2010 02:50 PM, Markos Chandras wrote: >> >>> >>> @Council: Yet another example that we need to track the status of every >>> single project in order to have a clear picture of which projects are >>> active and which are dead >>> >> >> Pruning projects that don't actively elect a lead would be a good start >> and that doesn't require anything from the council to be implemented. >> >> Regards, >> Petteri >> > Don't you think we need a team for that? Who is eligible to filter the project > list and ask status updates from them? > I think undertakers can take care of any possible cleanup commits as they already touch project pages for developer retirements. If you want to join for that purpose just be in contact with them and I think they will accept my proposal. As for just status queries I think anyone could query the status from projects and nothing special is required. Of course we should coordinate so that many simultaneous queries are not done. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] net-proxy/squid needs your love
On Wed, Aug 04, 2010 at 07:12:18PM +0300, Petteri Räty wrote: > On 08/04/2010 02:50 PM, Markos Chandras wrote: > > > > > @Council: Yet another example that we need to track the status of every > > single project in order to have a clear picture of which projects are > > active and which are dead > > > > Pruning projects that don't actively elect a lead would be a good start > and that doesn't require anything from the council to be implemented. > > Regards, > Petteri > Don't you think we need a team for that? Who is eligible to filter the project list and ask status updates from them? -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org Key ID: 441AC410 Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410 pgpMujenow85c.pgp Description: PGP signature
[gentoo-dev] Re: net-proxy/squid needs your love
On Wed, Aug 04, 2010 at 07:10:28PM +0200, Alin Năstac wrote: > Hi Markos, > > I'm very busy in real life, but I'll try to solve all squid issues this > week. > Btw, [2] and [3] were solved from net-proxy's perspective and [1] > wasn't fixed by upstream AFAIK. > > Cheers, > Alin > Hi Thanks for stepping up. If you need more manpower just yell and ask for help from our users. Furthermore, Kerin Millar did an excellent job on bug #311927 so you could work with him ( and co-maintain squid if you want ). That would be the best way imho to keep squid in a good shape :) Seems like my post created some noise and squid will move forward soon \o/ > On 04/08/2010 13:50, Markos Chandras wrote: > > Hi there > > > > net-proxy/squid needs your love. Bug #311927 and Bug #304751 require a > > version bump. Our user community did an excellent job there providing an > > improved ebuild for that. Furthermore there are several open security > > bugs wrt squid [1][2][3][4]. net-proxy herd what is your status? > > Security bugs should be your first priority. If you are unable to > > maintain certain packages you could ask for help instead of staying > > quiet. Maybe we should list this > > package as maintainer-needed and request some proxy-maintainers from our > > user community. What do you think about that? > > > > @Council: Yet another example that we need to track the status of every > > single project in order to have a clear picture of which projects are > > active and which are dead > > > > @QA: Should step up and commit these ebuilds just to get > > rid of the security bugs which, frankly, don't look that good ( distro > > wise ). I know technically is not our job, but we need to step up here > > and either fix the security bugs since net-proxy can't do that, or mask > > this package which is a no-go. > > > > [1] http://bugs.gentoo.org/261208 > > [2] http://bugs.gentoo.org/279379 > > [3] http://bugs.gentoo.org/279380 > > [4] http://bugs.gentoo.org/301828 > > > -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org Key ID: 441AC410 Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410 pgpV0cGlvHoZ6.pgp Description: PGP signature
[gentoo-dev] Re: net-proxy/squid needs your love
Hi Markos, I'm very busy in real life, but I'll try to solve all squid issues this week. Btw, [2] and [3] were solved from net-proxy's perspective and [1] wasn't fixed by upstream AFAIK. Cheers, Alin On 04/08/2010 13:50, Markos Chandras wrote: > Hi there > > net-proxy/squid needs your love. Bug #311927 and Bug #304751 require a > version bump. Our user community did an excellent job there providing an > improved ebuild for that. Furthermore there are several open security > bugs wrt squid [1][2][3][4]. net-proxy herd what is your status? > Security bugs should be your first priority. If you are unable to > maintain certain packages you could ask for help instead of staying > quiet. Maybe we should list this > package as maintainer-needed and request some proxy-maintainers from our > user community. What do you think about that? > > @Council: Yet another example that we need to track the status of every > single project in order to have a clear picture of which projects are > active and which are dead > > @QA: Should step up and commit these ebuilds just to get > rid of the security bugs which, frankly, don't look that good ( distro > wise ). I know technically is not our job, but we need to step up here > and either fix the security bugs since net-proxy can't do that, or mask > this package which is a no-go. > > [1] http://bugs.gentoo.org/261208 > [2] http://bugs.gentoo.org/279379 > [3] http://bugs.gentoo.org/279380 > [4] http://bugs.gentoo.org/301828 >
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-zope/datetime: ChangeLog datetime-2.12.5.ebuild
On Wednesday, August 04, 2010 08:22:23 Jeremy Olexa wrote:
> On 08/04/2010 03:05 AM, Peter Volkov wrote:
> > В Втр, 03/08/2010 в 17:12 -0500, Jeremy Olexa пишет:
> >> On Thu, 29 Jul 2010 20:22:47 + (UTC), "Arfrever Frehtes Taifersar
> >>
> >> Arahesis (arfrever)" wrote:
> >>>
> >>> SRC_URI="http://pypi.python.org/packages/source/${MY_PN:0:1}/${MY_PN}/$
> >>> {MY_P}.tar.gz"
> >>
> >> This is a perfect example of "over-complexification" - Why didn't you
> >> just use "D" instead of "${MY_PN:0:1}" ?
> >
> > Just take a look at pypi.python.org repository structure. This URL can
> > be copy&pasted from one package into another package from the same
> > repository without any changes...
>
> You can't copy/paste MY_PN, so while you are changing that, is it that
> hard to change *one* more character? Of the 290 ebuilds that use pypi,
> 172 of them use MY_PN. 83 use ${PN:0:1} for which your argument holds
> some water. As I said in the original message, I think we should strive
> for user friendly-ness but I guess I might be alone in that opinion. =/
i'm inclined to agree with you in general, but not in this particular case.
as the upstream repo is pretty well structured, and hosts many ebuild sources
for us, i'd go with Peter as i'm a fan of ebuilds that work when simply
renamed.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] net-proxy/squid needs your love
On 08/04/2010 02:50 PM, Markos Chandras wrote: > > @Council: Yet another example that we need to track the status of every > single project in order to have a clear picture of which projects are > active and which are dead > Pruning projects that don't actively elect a lead would be a good start and that doesn't require anything from the council to be implemented. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Package version in case of upstream patches from stable branch of development
On 4.8.2010 16.05, Peter Volkov wrote: > > Bug I mentioned pretends that we have policy how to set version for > packages that use backported upstream patches. Snapshotting a branch that is becoming next release is not backporting. Regards, Petteri
Re: [gentoo-dev] Package version in case of upstream patches from stable branch of development
В Срд, 04/08/2010 в 09:42 +, Jorge Manuel B. S. Vicetto пишет: > If you take KDE's team example, we provide ebuilds to track the stable > branch from upstream in our overlay. They're called .. > It's true that our ebuild does use the live vcs, but in this case the > difference is that instead of the users using a live ebuild, they get > a snapshot of the tree done by our maintainer from time to time. > Trying to pretend these "snapshot" ebuilds are the release version is > very wrong and no one should assume they'll build fine. Even for official upstream releases build tests are not enough. So there is not difference with _p here. > There are already a few bugs that can be attributed to this. Ok, let's say that this depends on upstream. And for Gentoo this means that the decision how to set version for the package depends on maintainer. Lot's of packages do not have dedicated release tests upstream (even build tests) and for this packages I don't see difference between stable branch and release. In such case our version just indicates that our package is base on tarbal of that version and nothing more. > The point here is that one thing is for a maintainer to pick specific > commits from the stable branch and back port them to fix some bugs, > another thing is to blindly fetch a snapshot of the stable branch. In reality it's hard to see difference if commit was done blindly or it was well tested until obvious crash happens. > It would be based on a release if it only applied specific patches to > fix known issues. The minute you start "tracking" a stable branch you > should stop calling it a release and 300kloc is not a "small" patch. Actually I think this limit depends on size of project. In any case until we have something documented that's up to maintainer... > This is unfortunately the main issue here. You may work on a specific > package on Gentoo, but when that package is essential for the system > use / stability, it stops being just "your" package. This latest > example has lead users to a point where their PM stopped working. > Breaking the PM is not a small "oops" That's completely different topic... I'm not talking about stability at all. Of course, python is special package and should be treated/tested by maintainers as such! Probably for such core packages ~arch is not enough and we need different process... But that a different topic. Bug I mentioned pretends that we have policy how to set version for packages that use backported upstream patches. My point is that there is no such policy and line between _p or -rN is very fuzzy to set such policy. Thus bug itself is INVALID... -- Peter.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-zope/datetime: ChangeLog datetime-2.12.5.ebuild
On 08/04/2010 03:05 AM, Peter Volkov wrote:
В Втр, 03/08/2010 в 17:12 -0500, Jeremy Olexa пишет:
On Thu, 29 Jul 2010 20:22:47 + (UTC), "Arfrever Frehtes Taifersar
Arahesis (arfrever)" wrote:
SRC_URI="http://pypi.python.org/packages/source/${MY_PN:0:1}/${MY_PN}/${MY_P}.tar.gz";
This is a perfect example of "over-complexification" - Why didn't you
just use "D" instead of "${MY_PN:0:1}" ?
Just take a look at pypi.python.org repository structure. This URL can
be copy&pasted from one package into another package from the same
repository without any changes...
You can't copy/paste MY_PN, so while you are changing that, is it that
hard to change *one* more character? Of the 290 ebuilds that use pypi,
172 of them use MY_PN. 83 use ${PN:0:1} for which your argument holds
some water. As I said in the original message, I think we should strive
for user friendly-ness but I guess I might be alone in that opinion. =/
-Jeremy
[gentoo-dev] net-proxy/squid needs your love
Hi there net-proxy/squid needs your love. Bug #311927 and Bug #304751 require a version bump. Our user community did an excellent job there providing an improved ebuild for that. Furthermore there are several open security bugs wrt squid [1][2][3][4]. net-proxy herd what is your status? Security bugs should be your first priority. If you are unable to maintain certain packages you could ask for help instead of staying quiet. Maybe we should list this package as maintainer-needed and request some proxy-maintainers from our user community. What do you think about that? @Council: Yet another example that we need to track the status of every single project in order to have a clear picture of which projects are active and which are dead @QA: Should step up and commit these ebuilds just to get rid of the security bugs which, frankly, don't look that good ( distro wise ). I know technically is not our job, but we need to step up here and either fix the security bugs since net-proxy can't do that, or mask this package which is a no-go. [1] http://bugs.gentoo.org/261208 [2] http://bugs.gentoo.org/279379 [3] http://bugs.gentoo.org/279380 [4] http://bugs.gentoo.org/301828 -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org pgplapthv4bOF.pgp Description: PGP signature
Re: [gentoo-dev] Package version in case of upstream patches from stable branch of development
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04-08-2010 07:56, Peter Volkov wrote: > В Втр, 03/08/2010 в 22:17 +0300, Petteri Räty пишет: >> On 08/03/2010 03:03 PM, Peter Volkov wrote: >>> Bug 330667 requests _p or _pre. I feel that _p|_pre versions >>> should be left for VCS (read development) versions of the >>> package, while during backports we have the best version with >>> all important upstream+gentoo fixes available to the moment and >>> I'd better avoid to call it development. >> >> If you read the bug you will see that our python has essentially >> been development versions so _p is in line with what you say >> above. > > Quotation from the bug: > > "gentoo's 3.1.2 is _not_ 3.1.2, it's a pre of 3.1.3." > > Not taking into consideration that it is possible to name _p 3.1.2 > I would like to point that patches are from _stable_ branch as thus > all users want them. This is not development version. If you take KDE's team example, we provide ebuilds to track the stable branch from upstream in our overlay. They're called .. It's true that our ebuild does use the live vcs, but in this case the difference is that instead of the users using a live ebuild, they get a snapshot of the tree done by our maintainer from time to time. Trying to pretend these "snapshot" ebuilds are the release version is very wrong and no one should assume they'll build fine. There are already a few bugs that can be attributed to this. >>> If we decide to go with _p or _pre could we agree on answers >>> for the following questions: - Does single patch from >>> upstream's VCS justify _p$(date|rev) version? What if this is >>> _the only_ patch in the upstream's VCS? >> >> No if the patch is small and can be reasonably understood. If the >> patch for example switches the used build system and I would >> think _p is called for. > >>> - Now what about two patches? Three? N? When does few patches >>> became pile? >> >> You should ask upstream to make a release when they start to pile >> up. > > Yup, but since "patchset being pile" is a clause to change version, > we should formally define what is a pile. 20kb unpacked? 10 > patches? Until this is done such decision is on maintainer's > discretion, like maintainer told in comment #1. The point here is that one thing is for a maintainer to pick specific commits from the stable branch and back port them to fix some bugs, another thing is to blindly fetch a snapshot of the stable branch. >>> - What if I drop single patch from the upstream's patchset for >>> stable branch, should we drop _pre _p version and add -rN? >> >> _p reflects upstream situation so dropping a patch from that is a >> Gentoo modification there so it would be _p12323-r1. > > Rigorously speaking even dropping one patch makes it not to be > _p12323 any more and we should version it somehow differently. How? > Since ebuild is based on upstream's stable tarbal obvious solution > is to use the tarbal's version. It would be based on a release if it only applied specific patches to fix known issues. The minute you start "tracking" a stable branch you should stop calling it a release and 300kloc is not a "small" patch. >>> - What if there are two dependent patches, and first one fixes >>> indentation? Should we spend time on backporting second patch >>> (time consuming and error prone process) or use both and live >>> closer to upstream? >> >> I would leave this up to the maintainer. Depends on how much >> time backporting takes. > > After reading your answers I don't understand why the bug is still > opened and what it is about. Arfrever told that he fells that it's > up to him how to version packages. And I agree with him in this > exact case. This is unfortunately the main issue here. You may work on a specific package on Gentoo, but when that package is essential for the system use / stability, it stops being just "your" package. This latest example has lead users to a point where their PM stopped working. Breaking the PM is not a small "oops" and doing it by continuously breaking our policies or ignoring one doesn't work alone, is a very serious offense. Should the toolchain team start providing "testing" gcc or glibc packages that have slight "oops" here and there that break systems? What about the kernel team deciding to mark stable some kernel versions with drivers that break hardware support without proper testing? Or what about the PERL team deciding they only care about the language and not the hundreds of packages that use it and start pushing new versions the day they're released no matter how many packages they break in the process? - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJMWTXuAAoJEC8ZTXQF1qEPp3EQAMfpoiEuXuPN8sWF1ZFG27M4 yvZC2ZLRfnp1mK8adT8LewkoVgBh4Plmyc0kaNZKBOMRUt
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-zope/datetime: ChangeLog datetime-2.12.5.ebuild
В Втр, 03/08/2010 в 17:12 -0500, Jeremy Olexa пишет:
> On Thu, 29 Jul 2010 20:22:47 + (UTC), "Arfrever Frehtes Taifersar
> Arahesis (arfrever)" wrote:
> >
> > SRC_URI="http://pypi.python.org/packages/source/${MY_PN:0:1}/${MY_PN}/${MY_P}.tar.gz";
> >
>
> This is a perfect example of "over-complexification" - Why didn't you
> just use "D" instead of "${MY_PN:0:1}" ?
Just take a look at pypi.python.org repository structure. This URL can
be copy&pasted from one package into another package from the same
repository without any changes...
--
Peter.
Re: [gentoo-dev] Package version in case of upstream patches from stable branch of development
В Втр, 03/08/2010 в 22:17 +0300, Petteri Räty пишет: > On 08/03/2010 03:03 PM, Peter Volkov wrote: > > Bug 330667 requests _p or > > _pre. I feel that _p|_pre versions should be left for VCS (read > > development) versions of the package, while during backports we have the > > best version with all important upstream+gentoo fixes available to the > > moment and I'd better avoid to call it development. > > If you read the bug you will see that our python has essentially been > development versions so _p is in line with what you say above. Quotation from the bug: "gentoo's 3.1.2 is _not_ 3.1.2, it's a pre of 3.1.3." Not taking into consideration that it is possible to name _p 3.1.2 I would like to point that patches are from _stable_ branch as thus all users want them. This is not development version. > > If we decide to go with _p or _pre could we agree on answers for the > > following questions: > > - Does single patch from upstream's VCS justify _p$(date|rev) version? > > What if this is _the only_ patch in the upstream's VCS? > > No if the patch is small and can be reasonably understood. If the patch > for example switches the used build system and I would think _p is > called for. > > - Now what about two patches? Three? N? When does few patches became > > pile? > > You should ask upstream to make a release when they start to pile up. Yup, but since "patchset being pile" is a clause to change version, we should formally define what is a pile. 20kb unpacked? 10 patches? Until this is done such decision is on maintainer's discretion, like maintainer told in comment #1. > > - What if I drop single patch from the upstream's patchset for stable > > branch, should we drop _pre _p version and add -rN? > > _p reflects upstream situation so dropping a patch from that is a Gentoo > modification there so it would be _p12323-r1. Rigorously speaking even dropping one patch makes it not to be _p12323 any more and we should version it somehow differently. How? Since ebuild is based on upstream's stable tarbal obvious solution is to use the tarbal's version. > > - What if there are two dependent patches, and first one fixes > > indentation? Should we spend time on backporting second patch (time > > consuming and error prone process) or use both and live closer to > > upstream? > > I would leave this up to the maintainer. Depends on how much time > backporting takes. After reading your answers I don't understand why the bug is still opened and what it is about. Arfrever told that he fells that it's up to him how to version packages. And I agree with him in this exact case. -- Peter.
