[gentoo-dev] Github PR commenting policy

[Fernando Rodriguez]

Github allows editting of comments in pull requests. Is there a policy 
regarding that? I've noticed a comment disappear which makes the rest of the 
conversation seem out of place.


-- 
Fernando Rodriguez

Re: [gentoo-dev] JFYIOR: A Simple Package Versioning Spec

[Matthew Thode]

On 09/18/2015 01:24 PM, konsolebox wrote:
> On Fri, Sep 18, 2015 at 11:38 PM, Matthew Thode
>  wrote:
>> Are you stating this is for package epochs?
> 
> I'm sorry but I'm not familiar with the term.  If you mean package
> versions, yes.
> 
> The current specification I also mentioned is this:
> https://projects.gentoo.org/pms/5/pms.html#x1-280003.2
> 

Nah, I'm talking about epochs.  When a package wishes to reversion
itself, changing how it does versioning.

For instance, nova is going to go from 2015.1.1 to 12.0.0, so 2015.n.x
is epoch 1, and 12.y.z is epoch 2.  Think of it like super versioning.

http://legacy.python.org/dev/peps/pep-0440/#version-epochs has a nice
summary.

-- 
-- Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] JFYIOR: A Simple Package Versioning Spec

[Kent Fredric]

On 19 September 2015 at 10:09, konsolebox  wrote:
> As for A6FGHKE and TRIAL, it's impossible to tell their actual level
> values so even if we choose to map them lexicographically, we would
> still not be able to use a universal algorithm that could tell how it
> affects the base version (just like how stages affects it) and how it
> compares with other values as well.  So it would still be up to the
> maintainer how he would represent the versions on ebuilds.
>
> One could do:
>
> Math-BaseCnv-1.6.20YYMMDD
>
> and
>
> Ubic-1.58.01.20YYMMDD or Ubic-1.58.01_pre20YYMMDD


And both of those translations would be wrong.

Math::BaseCnv's version is illegal even by Perl standards, but it uses
it anyway.

And that also means the is no way in Perl to declare you need
1.6.A6FG, any such dependency will either be treated as impossible to
satisfy, or satisfiable by all versions, and there is no way to even
*sort* versions that have invalid string components. Using a date
based segment in Gentoo will allow us to package the component itself,
but date order doesn't actually imply version order, they're just
highly similar. Which basically means even *if* we normalise it
somehow, any dependency we have on it in tree is just waiting to be
wrong.

Fortunately, cases like that are rare, and the associated yelling in
bug reports are preferred avoided.

And in the latter case, the "TRIAL" component is not actually part of
the version, but is itself a release-grade specifier, and just
so happens to be part of the *archive* name.

This is because CPAN upstream are not "archive" oriented dependencies,
but *module* oriented dependencies.

And an archive can have >1 modules and they may not all have the same version.

Hence, http://cpansearch.perl.org/src/MMCLERIC/Ubic-1.58_01-TRIAL/

Is actually just "1.58_01" + Alpha signifier

Which here is redundant, because the "_" is an alpha signifier as
well, and is deemed invisible in perl code.

Alas, there's a horrible historical bug in version.pm  that stupidly
treats "_" in any version as significant.

But either way, the right way to nomalise those versions is to elide
the _ and '-TRIAL' parts.

So the version is in fact: 1.5801  + ALPHA grade

And then you get to the horror of the fact CPAN has *2* versioning schemes:

   MAJOR.FLOATINGPART

   DECIMAL.DECIMAL.

Which means:

   1.58.1  is less than 1.58

Why?

Because 1.58.1 would be 1.058001   ( decimal to float conversion )
And 1.58 would be 1.58  ( float not converted due to only 2 parts )

This is the horror of mixing too many version schemes into the same namespace.

You get recurrent horrible gotchas that nobody intends on making, and
makes repeatedly.

The collective experience of Perl/CPAN and versions is that the
toolchain operators
wish we'd only ever had one version scheme, because there are just
*so* *many* *ways*
to confuse yourself when you switch from one scheme to another
thinking its fine.

And there are *so* *many* *ways* to royally cock it up, or do it the
best way possible, and then have
a downstream vendor not understand the reality of perl versions and
then have downstream make a mess of it.

For instance, downstreams without education are tend to see:

 1.1,  1.10 , 1.2, 1.20

as:

  1.1 , 1.2,  1.10, 1.20

When in reality, 1.10 = 1.10, and 1.2 == 1.20

In short: I'd rather Gentoo just had a tighter version scheme and good
tooling to allow mapping from one-scheme to another
on a case-by-case basis with forced normalised versions on the package itself.

Perl Herd are doing just that because it greatly simplifies version
interactions.


-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Re: [gentoo-dev] Re: New eclass: ros-catkin.eclass, new USE_EXPAND: ROS_MESSAGES, new categories: dev-ros and ros-meta for review.

[hasufell]

On 09/18/2015 11:06 AM, Alexis Ballier wrote:
>>
>> eclasses (and ebuilds) are always bash in gentoo and I'd vote for
>> writing "true" bash code, to stay consistent
>>
> 
> it is "true" bash :)
> 

No, it's compatibility mode. See bash manpage under "Compound Commands".

Re: [gentoo-dev] New eclass: ros-catkin.eclass, new USE_EXPAND: ROS_MESSAGES, new categories: dev-ros and ros-meta for review.

[hasufell]

How about something like

case ${EAPI} in
5) : ;;
*) die "EAPI=${EAPI:-0} is not supported" ;;
esac

to force people to stay up2date... then you can also drop most of those
redunant "|| die"s for EAPI functions


> 
> IUSE="test"
> RDEPEND="
>   dev-util/catkin${CATKIN_PYTHON_USEDEP}
>   dev-python/empy${CATKIN_PYTHON_USEDEP}
> "
> DEPEND="${RDEPEND}"
> 
> if [ -n "${CATKIN_DO_PYTHON_MULTIBUILD}" ] ; then
>   RDEPEND="${RDEPEND} dev-lang/python-exec:2"
> fi
> 
> # @ECLASS-VARIABLE: CATKIN_HAS_MESSAGES
> # @DESCRIPTION:
> # Set it to a non-empty value before inherit to tell the eclass the package 
> has messages to build.
> # Messages will be built based on ROS_MESSAGES USE_EXPANDed variable.
> 
> # @ECLASS-VARIABLE: CATKIN_MESSAGES_TRANSITIVE_DEPS
> # @DESCRIPTION:
> # Some messages have dependencies on other messages.
> # In that case, CATKIN_MESSAGES_TRANSITIVE_DEPS should contain a 
> space-separated list of atoms
> # representing those dependencies. The eclass uses it to ensure proper 
> dependencies on these packages. 
> if [ -n "${CATKIN_HAS_MESSAGES}" ] ; then
>   IUSE="${IUSE} +ros_messages_python +ros_messages_cxx ros_messages_eus 
> ros_messages_lisp"
>   RDEPEND="${RDEPEND}
>   ros_messages_cxx?( dev-ros/gencpp:=${CATKIN_PYTHON_USEDEP}  
> )
>   ros_messages_eus?( dev-ros/geneus:=${CATKIN_PYTHON_USEDEP}  
> )
>   ros_messages_python? ( dev-ros/genpy:=${CATKIN_PYTHON_USEDEP}   
> )
>   ros_messages_lisp?   ( dev-ros/genlisp:=${CATKIN_PYTHON_USEDEP} 
> )
>   dev-ros/message_runtime
>   "
>   DEPEND="${DEPEND} ${RDEPEND}
>   dev-ros/message_generation
>   dev-ros/genmsg${CATKIN_PYTHON_USEDEP}
>   "
>   if [ -n "${CATKIN_MESSAGES_TRANSITIVE_DEPS}" ] ; then
>   for i in ${CATKIN_MESSAGES_TRANSITIVE_DEPS} ; do
>   
> ds="${i}[ros_messages_python?,ros_messages_cxx?,ros_messages_lisp?,ros_messages_eus?]
>  ros_messages_python? ( ${i}[${PYTHON_USEDEP}] )"
>   RDEPEND="${RDEPEND} ${ds}"
>   DEPEND="${DEPEND} ${ds}"
>   done
>   fi
> fi
> 

Keep in mind what this implies when you change these dependencies
without bumping the ebuilds that use them.

> 
> # @FUNCTION: ros-catkin_src_test_internal
> # @DESCRIPTION:
> # Decorator around cmake-utils_src_test to ensure tests are built before 
> running them.
> ros-catkin_src_test_internal() {
>   cd "${BUILD_DIR}"

here is definitely a "|| die" missing, alternatively
emake -C "${BUILD_DIR}" ...
should work too and it seems cmake-utils_src_test already switches to
"${BUILD_DIR}" (with missing error handling, lol)



> 
> # @FUNCTION: ros-catkin_src_install_with_python
> # @DESCRIPTION:
> # Decorator around cmake-utils_src_install to ensure python scripts are 
> properly handled w.r.t. python-exec2.
> ros-catkin_src_install_with_python() {
>   python_export PYTHON_SCRIPTDIR
>   cmake-utils_src_install
>   if [ ! -f "${T}/.catkin_python_symlinks_generated" -a -d 
> "${D}/${PYTHON_SCRIPTDIR}" ]; then
>   dodir /usr/bin
>   for i in "${D}/${PYTHON_SCRIPTDIR}"/* ; do
>   dosym ../lib/python-exec/python-exec2 
> "/usr/bin/${i##*/}" || die
>   done
>   touch "${T}/.catkin_python_symlinks_generated"

touch can fail too, e.g. if the directory does not exist, so "|| die"
seems to make sense too

[gentoo-dev] Updating all Manifest to contain SHA256 SHA512 WHIRLPOOL

[Justin (jlec)]

Hello,

there are quite a number of Manifest still not containing one or more of the
three hashes. I would like to update them as far as we can download the sources.

Procedure would be:
1. Download package
2. verify current hashes match
3. Calculate new
4. commit

Following question need to be answered first:

Does anybody have any general objections, remarks or ideas on that?

2.
Any suggestion how to do this? repoman has a manifest-check function but that is
not functioning (bug filed). Any other tool around? Perhaps using pkgcheck?

Ugly hack would be, tampering the downloaded sources and run repoman manifest
which would redownload the tarball and check again.

4.
What do you think is the best commit mode? PKG based, Cat based or repo based?


Thanks for your comments,
Justin




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: New eclass: ros-catkin.eclass, new USE_EXPAND: ROS_MESSAGES, new categories: dev-ros and ros-meta for review.

[Alexis Ballier]

On Fri, 18 Sep 2015 10:37:04 +0200
hasufell  wrote:

> On 09/18/2015 10:30 AM, Alexis Ballier wrote:
> > On Thu, 17 Sep 2015 23:17:11 + (UTC)
> > Duncan <1i5t5.dun...@cox.net> wrote:
> > 
> >> Alexis Ballier posted on Thu, 17 Sep 2015 18:36:06 +0200 as
> >> excerpted:
> >>
> >>> if [ "${PV#}" != "${PV}" ] ; then
> >>>   SCM="git-r3"
> >>> fi
> >>
> >> [and elsewhere]
> >>
> >> I've seen this asked in other eclass review contexts, but not for 
> >> awhile...
> >>
> >> Since gentoo requires bash, why are you using old borne shell 
> >> compatibility test logic?  Why not use [[ ]] tests and avoid the
> >> need for the "", since bash then can treat variables as a unit and
> >> quotes are only needed if the tested strings include
> >> variable-external space (thus avoiding quote-logic errors if you
> >> accidentally forget the quotes)?
> >>
> > 
> > just a matter of taste I'd say: I'm used to write portable shell
> > code since, as you say, sometimes bash is not necessarily there, or
> > worse: in some worlds, gpl3, hence bash, is just banned.
> > 
> > because of this, I'm more used to the [ "" ] constructs and hence
> > find it prettier :) highly subjective though.
> > 
> > also, you can see the quotes around ${PV} aren't useful in that
> > context either, which is again just a matter of what my eyes are
> > used to see :)
> > 
> > Alexis.
> > 
> > [...]
> > 
> 
> eclasses (and ebuilds) are always bash in gentoo and I'd vote for
> writing "true" bash code, to stay consistent
> 

it is "true" bash :)

[gentoo-dev] JFYIOR: A Simple Package Versioning Spec

[konsolebox]

This is what an ideal and simple versioning spec should look like to
me.  (Not the form, but the concept).  I'm posting this here so it
could be used as an added reference to anyone that would consider
revising the current specification.

Note: Assigning default values can be bypassed depending on the implementation.

Comments are welcome.

1 Version Specification

A version is composed of four component sets: the base part, the
stage, the patch and the revision.

Each component is composed mainly of version nodes to represent their
level values.

When a component is not specified, it gets a default node value of {0}.

1.1 Version Nodes

Nodes start basically with a number and then is optionally followed by
a set of letters.

Numbers and letters can coexist alternatingly to represent a single
node.  The number of consecutive letters is also not limited to 1.
For example: "1a4xy" is allowed (can be restricted).

Each set of digits represents a single decimal number.  Leading zeros
hold no meaning.

The numerical equivalent of a set of letters is calculated in base of
27 (0 exists along with it but is not included as a symbol).

Version nodes after processing are basically just an array of signed
integers where each set of digits or letters are converted to their
numerical value.

1.2 Version Parts

1.2.1 The Base Part

The base version is simply a set of version nodes that are separated
by dots.  Examples: "4.1.2", "4.1.2aa" "4a", "4a.1", "4a.1.2".

After processing, the base version is an array of version nodes.

It is required.

1.2.2 The Stage Part

The stage part starts with _alpha, _beta, _pre or _rc.  Their
numerical values are -4, -3, -2 or -1 respectively.  Each of them can
optionally be followed by a version node string.  For example:
"_alpha01".

The resulting value for the stage after processing is a single version
node where the first value in it is the numerical values of _alpha,
_beta, _pre or _rc, and the other values are based on the added node
string.

A version without a stage has a default stage value of {0}.

The stage part is optional and can be specified only once after the
base part.  It can't be specified as a modifier for the patch, for the
revision, or for another stage.

1.2.3 The Patch Part

The patch part begins with _p and is followed by a version node
string.  For example: "_p20150105a".

The patch part is optional and can be specified after the base part or
after the stage part, but not after the revision.  It can only be
specified once.

It is processed as a single version node based on its version node string.

A version without a patch has a default patch value of {0}.

1.2.4 The Revision

The revision starts with -r and is followed by a number.

It is processed as a single version node based on its version node string.

A version without a revision has a default revision value of {0}.

1.3 Comparing Versions

Versions are compared as version nodes and the algorithm is simple:
each component and subcomponent is compared from left to right.

Anything that gives a difference decides which version is greater or lesser.

Any non-existing version-node has a default value of {0}.

Any non-existing element of a version node has a default value of 0.

If no difference is found during the process, it would mean that both
versions are equal.

1.3.1 Concept Code

  #!/usr/bin/ruby

  class ::Array
def adaptive_transpose
  h_size = self.max_by{ |a| a.size }.size
  v_size = self.size

  result = Array.new(h_size)
  with_index = self.each_with_index.to_a.freeze

  0.upto(h_size - 1) do |i|
result[i] = Array.new(v_size)
with_index.each{ |a, j| result[i][j] = a[i] }
  end

  result
end
  end

  module Portage
class PackageVersion
  class Node < ::Array
def initialize(*values)
  self.concat(values)
end

def compare_with(another)
  [self, another].adaptive_transpose.each do |a, b|
a ||= 0
b ||= 0
return -1 if a < b
return 1 if a > b
  end

  return 0
end

def self.parse(*args)
  result = new

  args.each do |a|
case a
when Integer
  result << a
when /^[[:digit:]][[:alnum:]]*$/
  a.scan(/[[:digit:]]+|[[:alpha:]]+/).each_with_index.map do |b, i|
if i.even?
  str = b.gsub(/^0+/, '')
  result << (str.empty? ? 0 : Integer(str))
else
  value = 0

  b.downcase.bytes.reverse.each_with_index do |c, i|
value += 27 ** i * (c - 96)  ## a == 1, z == 26,
and 0 exists but is not used
  end

  result << value
end
  end
else
  raise ArgumentError.new("Invalid node string: #{a.inspect}")
end
  end

   

Re: [gentoo-dev] Re: New eclass: ros-catkin.eclass, new USE_EXPAND: ROS_MESSAGES, new categories: dev-ros and ros-meta for review.

[hasufell]

On 09/18/2015 11:55 AM, Duncan wrote:
> Alexis Ballier posted on Fri, 18 Sep 2015 11:04:19 +0200 as excerpted:
> 
>>> Keep in mind what this implies when you change these dependencies
>>> without bumping the ebuilds that use them.
>>
>> only way i see these changing is with a new ros_messages_*** useflag,
>> which will cause a rebuild anyway
> 
> ??  Only with --newuse or similar, tho?  Otherwise USE (or USE_EXPAND 
> here) changes don't trigger rebuilds, do they?
> 

Correct. It's not good to rely on this and expect users to have a
certain update pattern or even use a particular PM.

Re: [gentoo-dev] Re: New eclass: ros-catkin.eclass, new USE_EXPAND: ROS_MESSAGES, new categories: dev-ros and ros-meta for review.

[hasufell]

On 09/18/2015 10:30 AM, Alexis Ballier wrote:
> On Thu, 17 Sep 2015 23:17:11 + (UTC)
> Duncan <1i5t5.dun...@cox.net> wrote:
> 
>> Alexis Ballier posted on Thu, 17 Sep 2015 18:36:06 +0200 as excerpted:
>>
>>> if [ "${PV#}" != "${PV}" ] ; then
>>> SCM="git-r3"
>>> fi
>>
>> [and elsewhere]
>>
>> I've seen this asked in other eclass review contexts, but not for 
>> awhile...
>>
>> Since gentoo requires bash, why are you using old borne shell 
>> compatibility test logic?  Why not use [[ ]] tests and avoid the need
>> for the "", since bash then can treat variables as a unit and quotes
>> are only needed if the tested strings include variable-external space
>> (thus avoiding quote-logic errors if you accidentally forget the
>> quotes)?
>>
> 
> just a matter of taste I'd say: I'm used to write portable shell code
> since, as you say, sometimes bash is not necessarily there, or worse: in
> some worlds, gpl3, hence bash, is just banned.
> 
> because of this, I'm more used to the [ "" ] constructs and hence find
> it prettier :) highly subjective though.
> 
> also, you can see the quotes around ${PV} aren't useful in that
> context either, which is again just a matter of what my eyes are used to
> see :)
> 
> Alexis.
> 
> [...]
> 

eclasses (and ebuilds) are always bash in gentoo and I'd vote for
writing "true" bash code, to stay consistent

[gentoo-dev] Re: New eclass: ros-catkin.eclass, new USE_EXPAND: ROS_MESSAGES, new categories: dev-ros and ros-meta for review.

[Duncan]

Alexis Ballier posted on Fri, 18 Sep 2015 11:04:19 +0200 as excerpted:

>> Keep in mind what this implies when you change these dependencies
>> without bumping the ebuilds that use them.
> 
> only way i see these changing is with a new ros_messages_*** useflag,
> which will cause a rebuild anyway

??  Only with --newuse or similar, tho?  Otherwise USE (or USE_EXPAND 
here) changes don't trigger rebuilds, do they?

-- 
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] JFYIOR: A Simple Package Versioning Spec

[Michał Górny]

Dnia 18 września 2015 11:32:15 CEST, konsolebox  
napisał(a):
>This is what an ideal and simple versioning spec should look like to
>me.  (Not the form, but the concept).  I'm posting this here so it
>could be used as an added reference to anyone that would consider
>revising the current specification.

The length of this mail itself proves that this is far from simple. And 
similarly to the current solution it's full of silly special cases and magical 
rules. If you really want something simple and clean, take a look at the scheme 
used by pkg-config and rpm.

>
>Note: Assigning default values can be bypassed depending on the
>implementation.
>
>Comments are welcome.
>
>1 Version Specification
>
>A version is composed of four component sets: the base part, the
>stage, the patch and the revision.
>
>Each component is composed mainly of version nodes to represent their
>level values.
>
>When a component is not specified, it gets a default node value of {0}.
>
>1.1 Version Nodes
>
>Nodes start basically with a number and then is optionally followed by
>a set of letters.
>
>Numbers and letters can coexist alternatingly to represent a single
>node.  The number of consecutive letters is also not limited to 1.
>For example: "1a4xy" is allowed (can be restricted).
>
>Each set of digits represents a single decimal number.  Leading zeros
>hold no meaning.
>
>The numerical equivalent of a set of letters is calculated in base of
>27 (0 exists along with it but is not included as a symbol).
>
>Version nodes after processing are basically just an array of signed
>integers where each set of digits or letters are converted to their
>numerical value.
>
>1.2 Version Parts
>
>1.2.1 The Base Part
>
>The base version is simply a set of version nodes that are separated
>by dots.  Examples: "4.1.2", "4.1.2aa" "4a", "4a.1", "4a.1.2".
>
>After processing, the base version is an array of version nodes.
>
>It is required.
>
>1.2.2 The Stage Part
>
>The stage part starts with _alpha, _beta, _pre or _rc.  Their
>numerical values are -4, -3, -2 or -1 respectively.  Each of them can
>optionally be followed by a version node string.  For example:
>"_alpha01".
>
>The resulting value for the stage after processing is a single version
>node where the first value in it is the numerical values of _alpha,
>_beta, _pre or _rc, and the other values are based on the added node
>string.
>
>A version without a stage has a default stage value of {0}.
>
>The stage part is optional and can be specified only once after the
>base part.  It can't be specified as a modifier for the patch, for the
>revision, or for another stage.
>
>1.2.3 The Patch Part
>
>The patch part begins with _p and is followed by a version node
>string.  For example: "_p20150105a".
>
>The patch part is optional and can be specified after the base part or
>after the stage part, but not after the revision.  It can only be
>specified once.
>
>It is processed as a single version node based on its version node
>string.
>
>A version without a patch has a default patch value of {0}.
>
>1.2.4 The Revision
>
>The revision starts with -r and is followed by a number.
>
>It is processed as a single version node based on its version node
>string.
>
>A version without a revision has a default revision value of {0}.
>
>1.3 Comparing Versions
>
>Versions are compared as version nodes and the algorithm is simple:
>each component and subcomponent is compared from left to right.
>
>Anything that gives a difference decides which version is greater or
>lesser.
>
>Any non-existing version-node has a default value of {0}.
>
>Any non-existing element of a version node has a default value of 0.
>
>If no difference is found during the process, it would mean that both
>versions are equal.
>
>1.3.1 Concept Code
>
>  #!/usr/bin/ruby
>
>  class ::Array
>def adaptive_transpose
>  h_size = self.max_by{ |a| a.size }.size
>  v_size = self.size
>
>  result = Array.new(h_size)
>  with_index = self.each_with_index.to_a.freeze
>
>  0.upto(h_size - 1) do |i|
>result[i] = Array.new(v_size)
>with_index.each{ |a, j| result[i][j] = a[i] }
>  end
>
>  result
>end
>  end
>
>  module Portage
>class PackageVersion
>  class Node < ::Array
>def initialize(*values)
>  self.concat(values)
>end
>
>def compare_with(another)
>  [self, another].adaptive_transpose.each do |a, b|
>a ||= 0
>b ||= 0
>return -1 if a < b
>return 1 if a > b
>  end
>
>  return 0
>end
>
>def self.parse(*args)
>  result = new
>
>  args.each do |a|
>case a
>when Integer
>  result << a
>when /^[[:digit:]][[:alnum:]]*$/
>  a.scan(/[[:digit:]]+|[[:alpha:]]+/).each_with_index.map do |b, i|
>if i.even?
>  str = b.gsub(/^0+/, '')

Re: [gentoo-dev] JFYIOR: A Simple Package Versioning Spec

[Vladimir Smirnov]

On Fri, 18 Sep 2015 23:16:43 +0800
konsolebox  wrote:

> If you avoid trying to adopt versioning practices which are far from
> practical and very far from common it is (as proven by the example
> code).  The workaround for such rare cases should be done on the
> ebuild's version.
> 

Just have a look on CPAN module versions. You'll see that it's much more common 
than you think. Just few examples:
http://search.cpan.org/~pip/Math-BaseCnv-1.6.A6FGHKE/
http://cpansearch.perl.org/src/MMCLERIC/Ubic-1.58_01-TRIAL/

And so on. There are much more than that. Also strange version translations, 
where new release may just start to use new version scheme. And so on, and so 
on.

Re: [gentoo-dev] JFYIOR: A Simple Package Versioning Spec

[konsolebox]

On Fri, Sep 18, 2015 at 11:38 PM, Matthew Thode
 wrote:
> Are you stating this is for package epochs?

I'm sorry but I'm not familiar with the term.  If you mean package
versions, yes.

The current specification I also mentioned is this:
https://projects.gentoo.org/pms/5/pms.html#x1-280003.2

Re: [gentoo-dev] JFYIOR: A Simple Package Versioning Spec

[konsolebox]

On Sat, Sep 19, 2015 at 2:58 AM, Matthew Thode
 wrote:
> On 09/18/2015 01:24 PM, konsolebox wrote:
>> On Fri, Sep 18, 2015 at 11:38 PM, Matthew Thode
>>  wrote:
>>> Are you stating this is for package epochs?
>>
>> I'm sorry but I'm not familiar with the term.  If you mean package
>> versions, yes.
>>
>> The current specification I also mentioned is this:
>> https://projects.gentoo.org/pms/5/pms.html#x1-280003.2
>>
>
> Nah, I'm talking about epochs.  When a package wishes to reversion
> itself, changing how it does versioning.
>
> For instance, nova is going to go from 2015.1.1 to 12.0.0, so 2015.n.x
> is epoch 1, and 12.y.z is epoch 2.  Think of it like super versioning.
>
No.. I believe it's up to the ebuild maintainer what versioning
strategy he'd use.  Personally I don't mind having 12.x.y and 2015.x.y
to co-exist.  You just have to mask 2015.x.y with keywords if
necessary.  Some packages actually mix version numbers.  It just
depends.

Re: [gentoo-dev] JFYIOR: A Simple Package Versioning Spec

[Raymond Jennings]

Gentoo is a distribution that incorporates heterogeneous software packages,
each of which may have their own versioning scheme.

We kinda have to treat the upstream version as an opaque blob because of
this.

Maybe I'm missing something but I don't think it's ok to screw with
upstream supplied version numbers.  Sorting them is fine but to me they
appear best treated as whole atoms that shouldn't be picked apart.

On Fri, Sep 18, 2015 at 6:02 PM, Kent Fredric  wrote:

> On 19 September 2015 at 10:09, konsolebox  wrote:
> > As for A6FGHKE and TRIAL, it's impossible to tell their actual level
> > values so even if we choose to map them lexicographically, we would
> > still not be able to use a universal algorithm that could tell how it
> > affects the base version (just like how stages affects it) and how it
> > compares with other values as well.  So it would still be up to the
> > maintainer how he would represent the versions on ebuilds.
> >
> > One could do:
> >
> > Math-BaseCnv-1.6.20YYMMDD
> >
> > and
> >
> > Ubic-1.58.01.20YYMMDD or Ubic-1.58.01_pre20YYMMDD
>
>
> And both of those translations would be wrong.
>
> Math::BaseCnv's version is illegal even by Perl standards, but it uses
> it anyway.
>
> And that also means the is no way in Perl to declare you need
> 1.6.A6FG, any such dependency will either be treated as impossible to
> satisfy, or satisfiable by all versions, and there is no way to even
> *sort* versions that have invalid string components. Using a date
> based segment in Gentoo will allow us to package the component itself,
> but date order doesn't actually imply version order, they're just
> highly similar. Which basically means even *if* we normalise it
> somehow, any dependency we have on it in tree is just waiting to be
> wrong.
>
> Fortunately, cases like that are rare, and the associated yelling in
> bug reports are preferred avoided.
>
> And in the latter case, the "TRIAL" component is not actually part of
> the version, but is itself a release-grade specifier, and just
> so happens to be part of the *archive* name.
>
> This is because CPAN upstream are not "archive" oriented dependencies,
> but *module* oriented dependencies.
>
> And an archive can have >1 modules and they may not all have the same
> version.
>
> Hence, http://cpansearch.perl.org/src/MMCLERIC/Ubic-1.58_01-TRIAL/
>
> Is actually just "1.58_01" + Alpha signifier
>
> Which here is redundant, because the "_" is an alpha signifier as
> well, and is deemed invisible in perl code.
>
> Alas, there's a horrible historical bug in version.pm  that stupidly
> treats "_" in any version as significant.
>
> But either way, the right way to nomalise those versions is to elide
> the _ and '-TRIAL' parts.
>
> So the version is in fact: 1.5801  + ALPHA grade
>
> And then you get to the horror of the fact CPAN has *2* versioning schemes:
>
>MAJOR.FLOATINGPART
>
>DECIMAL.DECIMAL.
>
> Which means:
>
>1.58.1  is less than 1.58
>
> Why?
>
> Because 1.58.1 would be 1.058001   ( decimal to float conversion )
> And 1.58 would be 1.58  ( float not converted due to only 2 parts )
>
> This is the horror of mixing too many version schemes into the same
> namespace.
>
> You get recurrent horrible gotchas that nobody intends on making, and
> makes repeatedly.
>
> The collective experience of Perl/CPAN and versions is that the
> toolchain operators
> wish we'd only ever had one version scheme, because there are just
> *so* *many* *ways*
> to confuse yourself when you switch from one scheme to another
> thinking its fine.
>
> And there are *so* *many* *ways* to royally cock it up, or do it the
> best way possible, and then have
> a downstream vendor not understand the reality of perl versions and
> then have downstream make a mess of it.
>
> For instance, downstreams without education are tend to see:
>
>  1.1,  1.10 , 1.2, 1.20
>
> as:
>
>   1.1 , 1.2,  1.10, 1.20
>
> When in reality, 1.10 = 1.10, and 1.2 == 1.20
>
> In short: I'd rather Gentoo just had a tighter version scheme and good
> tooling to allow mapping from one-scheme to another
> on a case-by-case basis with forced normalised versions on the package
> itself.
>
> Perl Herd are doing just that because it greatly simplifies version
> interactions.
>
>
> --
> Kent
>
> KENTNL - https://metacpan.org/author/KENTNL
>
>

Re: [gentoo-dev] Github PR commenting policy

[Michał Górny]

Dnia 2015-09-18, o godz. 20:09:16
Fernando Rodriguez  napisał(a):

> Github allows editting of comments in pull requests. Is there a policy 
> regarding that? I've noticed a comment disappear which makes the rest of the 
> conversation seem out of place.

We can't really do anything about that. However, we might soon be
mirroring all comments on Bugzilla where removing comments is not
permitted.

-- 
Best regards,
Michał Górny



pgpBn7du58imt.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] JFYIOR: A Simple Package Versioning Spec

[Michał Górny]

Dnia 2015-09-19, o godz. 03:50:52
konsolebox  napisał(a):

> On Sat, Sep 19, 2015 at 2:23 AM, Michał Górny  wrote:
> >
> >
> > Dnia 18 września 2015 11:32:15 CEST, konsolebox  
> > napisał(a):
> >>This is what an ideal and simple versioning spec should look like to
> >>me.  (Not the form, but the concept).  I'm posting this here so it
> >>could be used as an added reference to anyone that would consider
> >>revising the current specification.
> >
> > The length of this mail itself proves that this is far from simple.
> 
> Well that was called for yet still surprising.  I'm not sure how the
> length matters.  And imagine how longer it would have been if I used
> the 7 lexical algorithms of the current spec.

If you call something simple, make it simple. if it can't be
implemented simply, it's not simple. Simple as that.

> > And similarly to the current solution it's full of silly special cases and 
> > magical rules. If you really want something simple and clean, take a look 
> > at the scheme used by pkg-config and rpm.
> 
> Silly because it uses a not-so-monolithic approach which is more
> convenient to implement and actually works?  What special cases or
> magical rules where you could find it more complex than the current
> spec?

It's silly because it shifts the existing terrible structure a bit
and doesn't really solve most of its issues. It's silly because you
still have a fair number of limitations which make parsing harder
rather than easier. It's silly because you still have to remember
the relation between 'alpha', 'beta', 'rc' and 'pre'. It's silly
because those magical suffixes never match what upstreams use.
And those are just a few sillinesses.

>  It's all about converting version strings to numerical values
> and comparing them from left to right.  And the idea on how things are
> mapped is just a model and doesn't necessarily need to be followed
> when making an implementation.  If you don't want to allow "version
> nodes" and only allow a single letter after the last version number of
> the base part, then you could do it.  How you convert 4a to a form you
> could use for comparison is up to you - maybe just a struct with two
> integral fields would suffice.  But the idea of (1) using four
> sections: base, stage, patch and revision, (2) converting each
> sections to arrays or lists of integral numbers or finite-sized data
> forms usable for comparisons, and (3) comparing them simply from left
> to right, is there.

I don't really understand what this paragraph was supposed to mean. Are
you saying that your spec is fun because it's fun?

> To add: comparing version strings in converted numerical forms is
> friendly to the processor.  You can also cache converted forms if you
> want.  On the other hand using a train of lexical algorithms that
> parses and compares strings at the same time is painful to implement
> and yields mixed-up code.  Separating parsing from comparing is
> convenient.
> 
> And about pkg-config and rpm: I haven't thoroughly examined them yet,
> but you sure their implementation is applicable to Gentoo?  It might
> just turn simpler because it's more limited or strict.  Gentoo allows
> stages, patches and revisions and uses predefined prefixes.  Mine
> starts on a flexible approach where "version nodes" are allowed
> everywhere.

Then you should have. It is appreciated when people do some *research*
before throwing out random ideas on areas they have almost no idea of.

And to save you some time reading: the rpm implementation is simpler
and more flexible. It's free of stupidities like hardcoded suffix
lists or forced component ordering. Ordering (pre/post) is expressed
explicitly, and in many more cases you can avoid writing something
completely different than what upstream uses.

> If perhaps you mean to completely overhaul Gentoo's way of
> implementing package versions, I don't think that would work.

And is your change going to work? Because if you understood how ebuilds
work, you'd know you practically can't change versioning because you'd
immediately break compatibility between 'old' and 'new' ebuilds. This
isn't something that was designed to support changes in version scheme,
and changing that won't be anywhere close to easy. And if we ever agree
on doing that, we should go for a complete and useful solution rather
than some minor change with even smaller benefit.

> Just to remind you I'm presenting the idea, not the draft nor the
> implementation itself.  So don't pay too much attention on how it's
> made.  I think I should have given it a more abstract form, but this
> is just the first post.  I also hope you can give more specific or
> more elaborated criticizations about it, or perhaps give ideas on how
> it should be better implemented.

Also, you seem to have accidentally removed the mailing list from
To/CC.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] Inconsistent and messy layout of team maintainership in Gentoo

[Andreas K. Huettel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Freitag, 18. September 2015, 06:49:07 schrieb Robin H. Johnson:
> On Wed, Sep 16, 2015 at 11:43:02PM +0200, Andreas K. Huettel wrote:
>
> > a) Disallow the term "herd". Noone uses it correctly anyway.
> > 
> > b) package is "in herd" -> package is "maintained by project"
> > 
> > b') in metadata.xml x  ->  y
> 
> +1 on each.
> 
> > b'') simple and stupid mapping project y -> alias y-proj...@gentoo.org
> > 
> >( legacy y...@gentoo.org should be forwarded if possible )
> 
> Legacy addresses are not always so simple as y@, the can be like
> y-bugs@g.o as well.

I suspect that shouldn't really be a problem for legacy forwarding?
As long as we don't create new "irregular" addresses...

> > c) project membership implies project e-mail alias membership
> > 
> There are sometimes alias members that are NOT project members...
> 
> > d) per GLEP 39, only developers can be project members. introduce a
> > category
> > 
> >"contributors" who are also listed on the project page and are also
> >added to the project alias.
> 
> GLEP39 said devs only. It's already not the case, with non-dev members
> on the aliases.

Well... I don't really see the point of having people on the project alias who 
are not listed on the project page. After all we want to simplify things and 
not keep duplicate lists again.

(For just listening in on bugmail one can always "watch" an alias on 
bugzilla.)

About devs vs. non-devs, well we need to simplify this to one central list-
keeping place. Given the momentary wording of GLEP39, we can't list non-devs 
as project members on the wiki (which would be the authoritative source)- but 
we can certainly introduce an additional category of persons who gets added to 
the project alias the same way as devs / members (and listed on the project 
page in a prominent place). That's what I meant with introducing 
"contributors".

I have no strong opinion so far whether non-devs should be able to officially 
become project members, but if we want that we need to fix GLEP39 somehow.

- -- 

Andreas K. Huettel
Gentoo Linux developer 
dilfri...@gentoo.org
http://www.akhuettel.de/

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJV/I1NXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0RkJDMzI0NjNBOTIwMDY5MTQ2NkMzNDBF
MTM4NkZEN0VGNEI1Nzc5AAoJEOE4b9fvS1d5754QAI52pD17aEYzoFbzyO1M3ySn
fJ+7p+g7hwMUz1fM6EGDoN9zsHOnF0VKoc2YaFLD2SmlA7JDmL0PbPMmNPnwCICa
V0VR0J2OXDL40EMPiZHfuYZOPA7lMsfcmOx08Xil5psVkicDpKqXmksyUTM+gSub
ZkT/3LibkCq16svgDe0dP0Ma5XBiFS7K7kx4yd7M/IT3I7S0QqKYjLQCZExT2VBZ
Dsh+47/8bt78rpiUp1YNQSLk/jOQBTAWmPiXfrNE6rXF3XS9lI4D0fS9pjeLB2y6
PtpF7BwbPeLlqgMD5ePmKx+p/QzdCt7EFFJdft9inErGGY0Jxf2rlEdBxBQVhs2O
yYi7/wb4+mutbNewwlBFz+cHPvZm9k9zh+mdliIkcSh5xe1LIMz90LKqws6EnqtF
IOQtWpjdO37EdKjWnjz2+e+fc0oj2Oa1h0NP2a+Pan45sdQx/Ohm5NsHEzqiO/20
vQtRYzzXEfVUVzIgB3j5PfqX2mYaqNYCSVqgiSI6V00M2V0ynvgWlVBxEtz7/m78
3YP3W2FhlgZzVuEOwi1wuG2Ieh9Ryy4mYrcFYrQaWbuoBSDUb7pa8jmqbCGKHm9I
LV5/fIYhe2LXkMGATYAAzAIsCkt6hv8Ny2uFGOlwu25Ej8JXZvMHSblXoQmwqZID
J9sAxOVRtAWZEKL18bPF
=00/Y
-END PGP SIGNATURE-

Re: [gentoo-dev] JFYIOR: A Simple Package Versioning Spec

[konsolebox]

On Sat, Sep 19, 2015 at 4:11 AM, Vladimir Smirnov  wrote:
> On Fri, 18 Sep 2015 23:16:43 +0800
> konsolebox  wrote:
>
>> If you avoid trying to adopt versioning practices which are far from
>> practical and very far from common it is (as proven by the example
>> code).  The workaround for such rare cases should be done on the
>> ebuild's version.
>>
>
> Just have a look on CPAN module versions. You'll see that it's much more 
> common than you think. Just few examples:
> http://search.cpan.org/~pip/Math-BaseCnv-1.6.A6FGHKE/
> http://cpansearch.perl.org/src/MMCLERIC/Ubic-1.58_01-TRIAL/
>
> And so on. There are much more than that. Also strange version translations, 
> where new release may just start to use new version scheme. And so on, and so 
> on.

And the ambiguous part of the current spec which interprets numbers
starting with 0 differently didn't really help much in solving
problems in adapting those irregular versioning schemes.

That is why it's better to just implement a more simple and consistent
universal approach and keep the decisions on how those irregular
versions should be represented in ebuilds to the ebuild maintainers.

As for A6FGHKE and TRIAL, it's impossible to tell their actual level
values so even if we choose to map them lexicographically, we would
still not be able to use a universal algorithm that could tell how it
affects the base version (just like how stages affects it) and how it
compares with other values as well.  So it would still be up to the
maintainer how he would represent the versions on ebuilds.

One could do:

Math-BaseCnv-1.6.20YYMMDD

and

Ubic-1.58.01.20YYMMDD or Ubic-1.58.01_pre20YYMMDD

Re: [gentoo-dev] Inconsistent and messy layout of team maintainership in Gentoo

[Andreas K. Huettel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Freitag, 18. September 2015, 07:10:56 schrieb Michał Górny:
>
> 1. You can't list developers who are not subscribed on the wiki.

- -EDEVELOPER, or PEBKAC

I suspect this problem will go away very quickly once the aliases are 
generated from the wiki project member lists.

> 2. You can't list plain users (proxied maintainers) who work
> in the team. And yes, I know GLEP doesn't say they could.

As discussed in another sub-thread we can 
* either introduce an additional person category ("contributor") who gets 
added to the alias and listed on the project page in a prominent place
* or fix GLEP39

Both is likely doable.

- -- 

Andreas K. Huettel
Gentoo Linux developer 
dilfri...@gentoo.org
http://www.akhuettel.de/

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJV/JBqXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0RkJDMzI0NjNBOTIwMDY5MTQ2NkMzNDBF
MTM4NkZEN0VGNEI1Nzc5AAoJEOE4b9fvS1d5keMQAI2GmwXmj7nzebkXGTU03QL0
NO6OggdQr3J+4IqPTqx+9OypmZ2ns9V9Dq2QUEAid+VjS6+J2wUpCbxzDkcNE3wS
p7HtV0B5vtwcq66Tky9LCvVYO7Gw18oW1ik4v8isRW3CnyvnDW25tnbYtqz0syB0
3glIYPTSGLbSEK8nKgZAVJjq+Dl4E36c4a6MFvW0oqp1OWid/f9SYpSj6YCHtG7b
P/+5bORoM0h9Luuc+ItwiKJvMjluV9Lgjr+yW/QRooQ3uCJfdoJOvTG3IBBo555f
EuADbbgY5oPLcWw4wXIA4l2r8m5hRGkRP3eXDvgP2+sHBXEPN0LvpIdWO+S5ZwXN
LBlt/DZ13VXqBxN9iMedVuL60ayrcOj5bAMR+a4JalLPQLMjNDo/cyzwQYkdYvCZ
idCLgQ2fQgKP/aOwhT3JxTpWPU44VeCG2tZPLsmtqJCgtCnO2NwGfvxeOyoRbP/D
940ldUF5xFe8zwM2pvS5rxYV6xaNdhofl0qzyFSaQ+kdcKbgA65vXCBJj9gLGe5f
Ow1juNMb46hGiBjh3ngz58UKjO4GiI3lck1DVymIi4nwm9ek+8xEsqOWE+FGrQsx
fSaHHAycGd+uYQ1aazoZPhUMTOOzgJSMWEacC2mfFAj91FMMJB+qvWe76ZIn3fkr
7EeqH5eAo2e1cOMK1H3M
=7QzC
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: New eclass: ros-catkin.eclass, new USE_EXPAND: ROS_MESSAGES, new categories: dev-ros and ros-meta for review.

[hasufell]

On 09/18/2015 01:14 PM, Alexis Ballier wrote:
> On Fri, 18 Sep 2015 13:04:45 +0200
> hasufell  wrote:
> 
>> On 09/18/2015 12:56 PM, Alexis Ballier wrote:
>>> On Fri, 18 Sep 2015 11:58:09 +0200
>>> hasufell  wrote:
>>>
 On 09/18/2015 11:55 AM, Duncan wrote:
> Alexis Ballier posted on Fri, 18 Sep 2015 11:04:19 +0200 as
> excerpted:
>
>>> Keep in mind what this implies when you change these
>>> dependencies without bumping the ebuilds that use them.
>>
>> only way i see these changing is with a new ros_messages_***
>> useflag, which will cause a rebuild anyway
>
> ??  Only with --newuse or similar, tho?  Otherwise USE (or
> USE_EXPAND here) changes don't trigger rebuilds, do they?
>

 Correct. It's not good to rely on this and expect users to have a
 certain update pattern or even use a particular PM.

>>>
>>> then they wont have the messages if they don't rebuild, and
>>> cat/pkg[ros_messages_newthing] deps wont be satisfied and the pm
>>> will do the right thing by rebuilding.
>>> nothing to worry about, really.
>>>
>>
>> cat/pkg[ros_messages_newthing] will not be in users VDB until you
>> revbump cat/pkg, so I don't think it's that easy.
>>
> 
> and i think you're confused about what dynamic deps is and is not:
> cat/pkg[ros_messages_newthing] is not in vdb, so is not satisfied, so
> pm tries to find something that satisfies it from tree or dies.
> 

I'm not confused about dynamic deps, but about your example, because you
didn't say anything about revbumps.

If cat/pkg is not (rev)bumped, then there will be no check about whether
cat/pkg[ros_messages_newthing] is satisfied in the first place.

That was my point.

Re: [gentoo-dev] Re: New eclass: ros-catkin.eclass, new USE_EXPAND: ROS_MESSAGES, new categories: dev-ros and ros-meta for review.

[hasufell]

On 09/18/2015 12:56 PM, Alexis Ballier wrote:
> On Fri, 18 Sep 2015 11:58:09 +0200
> hasufell  wrote:
> 
>> On 09/18/2015 11:55 AM, Duncan wrote:
>>> Alexis Ballier posted on Fri, 18 Sep 2015 11:04:19 +0200 as
>>> excerpted:
>>>
> Keep in mind what this implies when you change these dependencies
> without bumping the ebuilds that use them.

 only way i see these changing is with a new ros_messages_***
 useflag, which will cause a rebuild anyway
>>>
>>> ??  Only with --newuse or similar, tho?  Otherwise USE (or
>>> USE_EXPAND here) changes don't trigger rebuilds, do they?
>>>
>>
>> Correct. It's not good to rely on this and expect users to have a
>> certain update pattern or even use a particular PM.
>>
> 
> then they wont have the messages if they don't rebuild, and
> cat/pkg[ros_messages_newthing] deps wont be satisfied and the pm will
> do the right thing by rebuilding.
> nothing to worry about, really.
> 

cat/pkg[ros_messages_newthing] will not be in users VDB until you
revbump cat/pkg, so I don't think it's that easy.

For adding a USE flag, you don't necessarily need a revbump, but you
can't hide another dep-fix behind a USE-flag addition.

Re: [gentoo-dev] Re: New eclass: ros-catkin.eclass, new USE_EXPAND: ROS_MESSAGES, new categories: dev-ros and ros-meta for review.

[Alexis Ballier]

On Fri, 18 Sep 2015 13:04:45 +0200
hasufell  wrote:

> On 09/18/2015 12:56 PM, Alexis Ballier wrote:
> > On Fri, 18 Sep 2015 11:58:09 +0200
> > hasufell  wrote:
> > 
> >> On 09/18/2015 11:55 AM, Duncan wrote:
> >>> Alexis Ballier posted on Fri, 18 Sep 2015 11:04:19 +0200 as
> >>> excerpted:
> >>>
> > Keep in mind what this implies when you change these
> > dependencies without bumping the ebuilds that use them.
> 
>  only way i see these changing is with a new ros_messages_***
>  useflag, which will cause a rebuild anyway
> >>>
> >>> ??  Only with --newuse or similar, tho?  Otherwise USE (or
> >>> USE_EXPAND here) changes don't trigger rebuilds, do they?
> >>>
> >>
> >> Correct. It's not good to rely on this and expect users to have a
> >> certain update pattern or even use a particular PM.
> >>
> > 
> > then they wont have the messages if they don't rebuild, and
> > cat/pkg[ros_messages_newthing] deps wont be satisfied and the pm
> > will do the right thing by rebuilding.
> > nothing to worry about, really.
> > 
> 
> cat/pkg[ros_messages_newthing] will not be in users VDB until you
> revbump cat/pkg, so I don't think it's that easy.
> 

and i think you're confused about what dynamic deps is and is not:
cat/pkg[ros_messages_newthing] is not in vdb, so is not satisfied, so
pm tries to find something that satisfies it from tree or dies.

this is exactly what happens with a >=cat/pkg-1 dep when only cat/pkg-0
is installed :)

Re: [gentoo-dev] Re: New eclass: ros-catkin.eclass, new USE_EXPAND: ROS_MESSAGES, new categories: dev-ros and ros-meta for review.

[hasufell]

On 09/18/2015 01:32 PM, hasufell wrote:
> On 09/18/2015 01:14 PM, Alexis Ballier wrote:
>> On Fri, 18 Sep 2015 13:04:45 +0200
>> hasufell  wrote:
>>
>>> On 09/18/2015 12:56 PM, Alexis Ballier wrote:
 On Fri, 18 Sep 2015 11:58:09 +0200
 hasufell  wrote:

> On 09/18/2015 11:55 AM, Duncan wrote:
>> Alexis Ballier posted on Fri, 18 Sep 2015 11:04:19 +0200 as
>> excerpted:
>>
 Keep in mind what this implies when you change these
 dependencies without bumping the ebuilds that use them.
>>>
>>> only way i see these changing is with a new ros_messages_***
>>> useflag, which will cause a rebuild anyway
>>
>> ??  Only with --newuse or similar, tho?  Otherwise USE (or
>> USE_EXPAND here) changes don't trigger rebuilds, do they?
>>
>
> Correct. It's not good to rely on this and expect users to have a
> certain update pattern or even use a particular PM.
>

 then they wont have the messages if they don't rebuild, and
 cat/pkg[ros_messages_newthing] deps wont be satisfied and the pm
 will do the right thing by rebuilding.
 nothing to worry about, really.

>>>
>>> cat/pkg[ros_messages_newthing] will not be in users VDB until you
>>> revbump cat/pkg, so I don't think it's that easy.
>>>
>>
>> and i think you're confused about what dynamic deps is and is not:
>> cat/pkg[ros_messages_newthing] is not in vdb, so is not satisfied, so
>> pm tries to find something that satisfies it from tree or dies.
>>
> 
> I'm not confused about dynamic deps, but about your example, because you
> didn't say anything about revbumps.
> 
> If cat/pkg is not (rev)bumped, then there will be no check about whether
> cat/pkg[ros_messages_newthing] is satisfied in the first place.
> 

correcting: if the package adding cat/pkg[ros_messages_newthing] is not
(rev)bumped

Re: [gentoo-dev] Re: New eclass: ros-catkin.eclass, new USE_EXPAND: ROS_MESSAGES, new categories: dev-ros and ros-meta for review.

[Alexis Ballier]

On Fri, 18 Sep 2015 13:33:08 +0200
hasufell  wrote:

> On 09/18/2015 01:32 PM, hasufell wrote:
> > On 09/18/2015 01:14 PM, Alexis Ballier wrote:
> >> On Fri, 18 Sep 2015 13:04:45 +0200
> >> hasufell  wrote:
> >>
> >>> On 09/18/2015 12:56 PM, Alexis Ballier wrote:
>  On Fri, 18 Sep 2015 11:58:09 +0200
>  hasufell  wrote:
> 
> > On 09/18/2015 11:55 AM, Duncan wrote:
> >> Alexis Ballier posted on Fri, 18 Sep 2015 11:04:19 +0200 as
> >> excerpted:
> >>
>  Keep in mind what this implies when you change these
>  dependencies without bumping the ebuilds that use them.
> >>>
> >>> only way i see these changing is with a new ros_messages_***
> >>> useflag, which will cause a rebuild anyway
> >>
> >> ??  Only with --newuse or similar, tho?  Otherwise USE (or
> >> USE_EXPAND here) changes don't trigger rebuilds, do they?
> >>
> >
> > Correct. It's not good to rely on this and expect users to have
> > a certain update pattern or even use a particular PM.
> >
> 
>  then they wont have the messages if they don't rebuild, and
>  cat/pkg[ros_messages_newthing] deps wont be satisfied and the pm
>  will do the right thing by rebuilding.
>  nothing to worry about, really.
> 
> >>>
> >>> cat/pkg[ros_messages_newthing] will not be in users VDB until you
> >>> revbump cat/pkg, so I don't think it's that easy.
> >>>
> >>
> >> and i think you're confused about what dynamic deps is and is not:
> >> cat/pkg[ros_messages_newthing] is not in vdb, so is not satisfied,
> >> so pm tries to find something that satisfies it from tree or dies.
> >>
> > 
> > I'm not confused about dynamic deps, but about your example,
> > because you didn't say anything about revbumps.
> > 
> > If cat/pkg is not (rev)bumped, then there will be no check about
> > whether cat/pkg[ros_messages_newthing] is satisfied in the first
> > place.
> > 
> 
> correcting: if the package adding cat/pkg[ros_messages_newthing] is
> not (rev)bumped

yes, this one will be bumped, and this is not part of the eclass

Re: [gentoo-dev] Re: New eclass: ros-catkin.eclass, new USE_EXPAND: ROS_MESSAGES, new categories: dev-ros and ros-meta for review.

[Alexis Ballier]

On Fri, 18 Sep 2015 11:58:09 +0200
hasufell  wrote:

> On 09/18/2015 11:55 AM, Duncan wrote:
> > Alexis Ballier posted on Fri, 18 Sep 2015 11:04:19 +0200 as
> > excerpted:
> > 
> >>> Keep in mind what this implies when you change these dependencies
> >>> without bumping the ebuilds that use them.
> >>
> >> only way i see these changing is with a new ros_messages_***
> >> useflag, which will cause a rebuild anyway
> > 
> > ??  Only with --newuse or similar, tho?  Otherwise USE (or
> > USE_EXPAND here) changes don't trigger rebuilds, do they?
> > 
> 
> Correct. It's not good to rely on this and expect users to have a
> certain update pattern or even use a particular PM.
> 

then they wont have the messages if they don't rebuild, and
cat/pkg[ros_messages_newthing] deps wont be satisfied and the pm will
do the right thing by rebuilding.
nothing to worry about, really.

makes me think it'd be better to use (-) usedeps there, just to comply
with the half-broken definition of eapi2-style usedeps

Re: [gentoo-dev] Re: New eclass: ros-catkin.eclass, new USE_EXPAND: ROS_MESSAGES, new categories: dev-ros and ros-meta for review.

[Alexis Ballier]

On Fri, 18 Sep 2015 13:04:45 +0200
hasufell  wrote:

> On 09/18/2015 12:56 PM, Alexis Ballier wrote:
> > On Fri, 18 Sep 2015 11:58:09 +0200
> > hasufell  wrote:
> > 
> >> On 09/18/2015 11:55 AM, Duncan wrote:
> >>> Alexis Ballier posted on Fri, 18 Sep 2015 11:04:19 +0200 as
> >>> excerpted:
> >>>
> > Keep in mind what this implies when you change these
> > dependencies without bumping the ebuilds that use them.
> 
>  only way i see these changing is with a new ros_messages_***
>  useflag, which will cause a rebuild anyway
> >>>
> >>> ??  Only with --newuse or similar, tho?  Otherwise USE (or
> >>> USE_EXPAND here) changes don't trigger rebuilds, do they?
> >>>
> >>
> >> Correct. It's not good to rely on this and expect users to have a
> >> certain update pattern or even use a particular PM.
> >>
> > 
> > then they wont have the messages if they don't rebuild, and
> > cat/pkg[ros_messages_newthing] deps wont be satisfied and the pm
> > will do the right thing by rebuilding.
> > nothing to worry about, really.
> > 
> 
> cat/pkg[ros_messages_newthing] will not be in users VDB until you
> revbump cat/pkg, so I don't think it's that easy.
> 
> For adding a USE flag, you don't necessarily need a revbump, but you
> can't hide another dep-fix behind a USE-flag addition.


you misunderstood i think:
packages that will add this dep are of course revbumped (usually
verbumped actually)
dep addition from within the eclass is tied to useflag addition

Re: [gentoo-dev] Inconsistent and messy layout of team maintainership in Gentoo

[Rich Freeman]

On Fri, Sep 18, 2015 at 1:10 AM, Michał Górny  wrote:
> Dnia 2015-09-17, o godz. 17:19:17
> Michael Orlitzky  napisał(a):
>
>> Replying somewhere randomly with an idea.
>>
>> Since projects are now on the wiki, why don't we use that as the
>> canonical source of project members? It's machine readable, although not
>> so nice to have it located outside the repo/ldap.
>
> How about... because:
>
> 1. You can't list developers who are not subscribed on the wiki. I've
> asked for some solution multiple times, and so far people are just
> INVALID-ating the bugs and pointing fingers. Of course, it could be
> partially related to the fact that we still don't have any SSO for
> Gentoo services, and have to ask people to sign up manually everywhere.

I'd have to dig up whether we actually took a vote, but I'm pretty
sure the council doesn't consider this a problem.  If people want to
contribute, they can sign up for the wiki.  It isn't like it is one of
those even non-FOSS tools.

However, I think the rest of your concerns are valid, especially the
concern about being able to include non-devs on aliases (whether you
consider them "members" or not).  I don't have a problem with asking
them to sign up on the wiki, but we'd need to change the templates/etc
so that they can still be listed somewhere on the project.  And of
course somebody has to build it.

-- 
Rich

Re: [gentoo-dev] [PATCH dtd] herds: Remove no-longer usable element

[Ulrich Mueller]

> On Thu, 17 Sep 2015, Michał Górny wrote:

>> Let's please first decide on the greater scheme of projects, teams,
>> and herds. Starting to change files before we have any plan doesn't
>> make sense.

> We already decided we move projects to Wiki. I don't think we're
> going to decide to move them to GuideXML ever again. Keeping an
> element dedicated to that doesn't make any sense because it can
> never work again.

Updating herds.xml implies that we are going to keep the concept of
herds, and there is no decision on that yet.

IIUC keeping an obsolete element in the DTD doesn't actually break
anything, so I don't see the urgency of removing it.

Ulrich


pgpYZ4U7tWQHI.pgp
Description: PGP signature

Re: [gentoo-dev] Re: New eclass: ros-catkin.eclass, new USE_EXPAND: ROS_MESSAGES, new categories: dev-ros and ros-meta for review.

[Alexis Ballier]

On Thu, 17 Sep 2015 23:17:11 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:

> Alexis Ballier posted on Thu, 17 Sep 2015 18:36:06 +0200 as excerpted:
> 
> > if [ "${PV#}" != "${PV}" ] ; then
> > SCM="git-r3"
> > fi
> 
> [and elsewhere]
> 
> I've seen this asked in other eclass review contexts, but not for 
> awhile...
> 
> Since gentoo requires bash, why are you using old borne shell 
> compatibility test logic?  Why not use [[ ]] tests and avoid the need
> for the "", since bash then can treat variables as a unit and quotes
> are only needed if the tested strings include variable-external space
> (thus avoiding quote-logic errors if you accidentally forget the
> quotes)?
> 

just a matter of taste I'd say: I'm used to write portable shell code
since, as you say, sometimes bash is not necessarily there, or worse: in
some worlds, gpl3, hence bash, is just banned.

because of this, I'm more used to the [ "" ] constructs and hence find
it prettier :) highly subjective though.

also, you can see the quotes around ${PV} aren't useful in that
context either, which is again just a matter of what my eyes are used to
see :)

Alexis.

[...]

OpenPGP verification of source files (was: Re: [gentoo-dev] Updating all Manifest to contain SHA256 SHA512 WHIRLPOOL)

[Kristian Fiskerstrand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 09/18/2015 10:58 AM, Justin (jlec) wrote:
> Hello,
> 
> there are quite a number of Manifest still not containing one or
> more of the three hashes. I would like to update them as far as we
> can download the sources.
> 
> Procedure would be: 1. Download package 2. verify current hashes
> match 3. Calculate new 4. commit
> 
> Following question need to be answered first:
> 
> Does anybody have any general objections, remarks or ideas on
> that?

As long as the current hashes are verified for the download I'm fine
with this, but I'd like to take the opportunity to bring up a general
note with regards to manifest generation and OpenPGP verification of
source files.

Now that we're hopefully getting closer to a fully signed OpenPGP
Gentoo Tree, it is also important that package maintainers pay
attention to OpenPGP signatures when generating the initial manifest
files e.g. on a version bump. This also brings up some interesting key
management issues with regards to ensuring that the package is signed
with the correct key. Of course, where the maintainer has met the
developer and cross-signed the keys, this part is relatively easy, as
the key will have full validity or can be easily verified by one hope
distance.

Where this becomes more difficult is of course where no direct
certification has been made, leading into more probabilistic
approaches to determining key validity. I would expect maintainers of
a package following the mailing lists giving a high expectation of the
key being correct, and as such keeping a local copy of the keys used
for distribution with a local signature (lsign in GnuPG's edit-key
interface) marking this key as valid.

We currently don't (well, I don't at least) store information about
the file verification in the git commit messages, and I'm not sure if
this is something that would be valuable exceeding the cost of the
added message and finding a format to do so. But given that we're
talking about the manifests, I do sincerely hope package maintainers
have a well thought out setup for key management locally and in fact
verify the OpenPGP signatures vs known good keys, and that appropriate
measures are being taken in the case of non-maintainer commits that
doesn't reduce the level of security.

- -- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJV+9Z8AAoJECULev7WN52FgucH/jN6bwIe/AJuv6y2VkVC7gT2
pdtZY4hEv2TlVJUcGKgMfk5BWD2vm0vBdOCTwyPMgNXf+fnXv70507RmReecRiyB
ouVgacu1nQYMCG2urvuQckXPdGfycbgk0ESe+XcKbRnOmmJ2a4ZVKENXk0TbA38Y
hJ/c2boxpJiVZHF6JSPwfXBrC0j6GpRsLnce/vKybH0uDye4/7Q1Hw9R76KQDATd
DB+hcAsQfonj7rDy4FoKviuiSiZmbHam0yCQGiBaR2fqQOc+erSJ29Hy+MLkdCCa
Zy36sUv299u71J/9LYXuQBpeULV0XQ82ERz1VuJ6SV4YPYRtroqoKmnasA77Prw=
=bV4C
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: New eclass: ros-catkin.eclass, new USE_EXPAND: ROS_MESSAGES, new categories: dev-ros and ros-meta for review.

[hasufell]

On 09/18/2015 11:10 AM, hasufell wrote:
> On 09/18/2015 11:06 AM, Alexis Ballier wrote:
>>>
>>> eclasses (and ebuilds) are always bash in gentoo and I'd vote for
>>> writing "true" bash code, to stay consistent
>>>
>>
>> it is "true" bash :)
>>
> 
> No, it's compatibility mode. See bash manpage under "Compound Commands".
> 

Anyway, both works, so there's no reason to debate a lot over this.

Re: [gentoo-dev] New eclass: ros-catkin.eclass, new USE_EXPAND: ROS_MESSAGES, new categories: dev-ros and ros-meta for review.

[hasufell]

On 09/17/2015 06:36 PM, Alexis Ballier wrote:
> 
> # @ECLASS-VARIABLE: PYTHON_COMPAT
> # @DESCRIPTION:
> # Tells the eclass the package has python code and forwards it to 
> python-r1.eclass.
> PYTHON_ECLASS=""
> CATKIN_PYTHON_USEDEP=""
> if [ -n "${PYTHON_COMPAT}" ] ; then
> PYTHON_ECLASS="python-r1 python-utils-r1"
> fi

see python-r1.eclass:
"""
# Please note that python-r1 will always inherit python-utils-r1 as
# well. Thus, all the functions defined there can be used
# in the packages using python-r1, and there is no need ever to inherit
# both.
"""

> # @FUNCTION: ros-catkin_src_install_with_python
> # @DESCRIPTION:
> # Decorator around cmake-utils_src_install to ensure python scripts are 
> properly handled w.r.t. python-exec2.
> ros-catkin_src_install_with_python() {
>   python_export PYTHON_SCRIPTDIR
>   cmake-utils_src_install
>   if [ ! -f "${T}/.catkin_python_symlinks_generated" -a -d 
> "${D}/${PYTHON_SCRIPTDIR}" ]; then
>   dodir /usr/bin
>   for i in "${D}/${PYTHON_SCRIPTDIR}"/* ; do
>   dosym ../lib/python-exec/python-exec2 
> "/usr/bin/${i##*/}" || die
>   done
>   touch "${T}/.catkin_python_symlinks_generated"
>   fi
> }

Maybe I don't understand the purpose, but this looks like a hack
that is trying to circumvent the python eclasses.

You probably should have a look at:
"""
# @FUNCTION: python_replicate_script
# @USAGE: ...
# @DESCRIPTION:
# Copy the given script to variants for all enabled Python
# implementations, then replace it with a symlink to the wrapper.
#
# All specified files must start with a 'python' shebang. A file not
# having a matching shebang will be refused.
"""


> 
> # @FUNCTION: ros-catkin_src_compile
> # @DESCRIPTION:
> # Builds a catkin-based package.
> ros-catkin_src_compile() {
>   if [ -n "${CATKIN_DO_PYTHON_MULTIBUILD}" ] ; then
>   python_foreach_impl cmake-utils_src_compile
>   else
>   cmake-utils_src_compile
>   fi
> }
> 

> 
> # @FUNCTION: ros-catkin_src_test
> # @DESCRIPTION:
> # Run the tests of a catkin-based package.
> ros-catkin_src_test() {
>   if [ -n "${CATKIN_DO_PYTHON_MULTIBUILD}" ] ; then
>   python_foreach_impl ros-catkin_src_test_internal
>   else
>   ros-catkin_src_test_internal
>   fi
> }
> 

> 
> # @FUNCTION: ros-catkin_src_install
> # @DESCRIPTION:
> # Installs a catkin-based package.
> ros-catkin_src_install() {
>   if [ -n "${CATKIN_DO_PYTHON_MULTIBUILD}" ] ; then
>   python_foreach_impl ros-catkin_src_install_with_python
>   else
>   cmake-utils_src_install
>   fi
> }
> 

I think these functions should pass arguments through to cmake-utils_src_* 
functions,
so an ebuild might be able to do stuff like
  ros-catkin_src_compile -j1
or other things if that is really needed.

Re: [gentoo-dev] JFYIOR: A Simple Package Versioning Spec

[konsolebox]

On Fri, Sep 18, 2015 at 10:01 PM, Ciaran McCreesh
 wrote:
> On Fri, 18 Sep 2015 17:32:15 +0800
> konsolebox  wrote:
>> This is what an ideal and simple versioning spec should look like to
>> me.
>
> Versioning isn't ideal and simple.

If you avoid trying to adopt versioning practices which are far from
practical and very far from common it is (as proven by the example
code).  The workaround for such rare cases should be done on the
ebuild's version.

Re: [gentoo-dev] JFYIOR: A Simple Package Versioning Spec

[Matthew Thode]

On 09/18/2015 04:32 AM, konsolebox wrote:
> This is what an ideal and simple versioning spec should look like to
> me.  (Not the form, but the concept).  I'm posting this here so it
> could be used as an added reference to anyone that would consider
> revising the current specification.
> 
> Note: Assigning default values can be bypassed depending on the 
> implementation.
> 
> Comments are welcome.
> 
> 1 Version Specification
> 
> A version is composed of four component sets: the base part, the
> stage, the patch and the revision.
> 
> Each component is composed mainly of version nodes to represent their
> level values.
> 
> When a component is not specified, it gets a default node value of {0}.
> 
> 1.1 Version Nodes
> 
> Nodes start basically with a number and then is optionally followed by
> a set of letters.
> 
> Numbers and letters can coexist alternatingly to represent a single
> node.  The number of consecutive letters is also not limited to 1.
> For example: "1a4xy" is allowed (can be restricted).
> 
> Each set of digits represents a single decimal number.  Leading zeros
> hold no meaning.
> 
> The numerical equivalent of a set of letters is calculated in base of
> 27 (0 exists along with it but is not included as a symbol).
> 
> Version nodes after processing are basically just an array of signed
> integers where each set of digits or letters are converted to their
> numerical value.
> 
> 1.2 Version Parts
> 
> 1.2.1 The Base Part
> 
> The base version is simply a set of version nodes that are separated
> by dots.  Examples: "4.1.2", "4.1.2aa" "4a", "4a.1", "4a.1.2".
> 
> After processing, the base version is an array of version nodes.
> 
> It is required.
> 
> 1.2.2 The Stage Part
> 
> The stage part starts with _alpha, _beta, _pre or _rc.  Their
> numerical values are -4, -3, -2 or -1 respectively.  Each of them can
> optionally be followed by a version node string.  For example:
> "_alpha01".
> 
> The resulting value for the stage after processing is a single version
> node where the first value in it is the numerical values of _alpha,
> _beta, _pre or _rc, and the other values are based on the added node
> string.
> 
> A version without a stage has a default stage value of {0}.
> 
> The stage part is optional and can be specified only once after the
> base part.  It can't be specified as a modifier for the patch, for the
> revision, or for another stage.
> 
> 1.2.3 The Patch Part
> 
> The patch part begins with _p and is followed by a version node
> string.  For example: "_p20150105a".
> 
> The patch part is optional and can be specified after the base part or
> after the stage part, but not after the revision.  It can only be
> specified once.
> 
> It is processed as a single version node based on its version node string.
> 
> A version without a patch has a default patch value of {0}.
> 
> 1.2.4 The Revision
> 
> The revision starts with -r and is followed by a number.
> 
> It is processed as a single version node based on its version node string.
> 
> A version without a revision has a default revision value of {0}.
> 
> 1.3 Comparing Versions
> 
> Versions are compared as version nodes and the algorithm is simple:
> each component and subcomponent is compared from left to right.
> 
> Anything that gives a difference decides which version is greater or lesser.
> 
> Any non-existing version-node has a default value of {0}.
> 
> Any non-existing element of a version node has a default value of 0.
> 
> If no difference is found during the process, it would mean that both
> versions are equal.
> 
> 1.3.1 Concept Code
> 
>   #!/usr/bin/ruby
> 
>   class ::Array
> def adaptive_transpose
>   h_size = self.max_by{ |a| a.size }.size
>   v_size = self.size
> 
>   result = Array.new(h_size)
>   with_index = self.each_with_index.to_a.freeze
> 
>   0.upto(h_size - 1) do |i|
> result[i] = Array.new(v_size)
> with_index.each{ |a, j| result[i][j] = a[i] }
>   end
> 
>   result
> end
>   end
> 
>   module Portage
> class PackageVersion
>   class Node < ::Array
> def initialize(*values)
>   self.concat(values)
> end
> 
> def compare_with(another)
>   [self, another].adaptive_transpose.each do |a, b|
> a ||= 0
> b ||= 0
> return -1 if a < b
> return 1 if a > b
>   end
> 
>   return 0
> end
> 
> def self.parse(*args)
>   result = new
> 
>   args.each do |a|
> case a
> when Integer
>   result << a
> when /^[[:digit:]][[:alnum:]]*$/
>   a.scan(/[[:digit:]]+|[[:alpha:]]+/).each_with_index.map do |b, 
> i|
> if i.even?
>   str = b.gsub(/^0+/, '')
>   result << (str.empty? ? 0 : Integer(str))
> else
>   value = 0
> 
>   

Re: [gentoo-dev] New eclass: ros-catkin.eclass, new USE_EXPAND: ROS_MESSAGES, new categories: dev-ros and ros-meta for review.

[Alexis Ballier]

On Fri, 18 Sep 2015 18:28:09 +0200
hasufell  wrote:

> On 09/17/2015 06:36 PM, Alexis Ballier wrote:
> > 
> > # @ECLASS-VARIABLE: PYTHON_COMPAT
> > # @DESCRIPTION:
> > # Tells the eclass the package has python code and forwards it to
> > python-r1.eclass. PYTHON_ECLASS=""
> > CATKIN_PYTHON_USEDEP=""
> > if [ -n "${PYTHON_COMPAT}" ] ; then
> > PYTHON_ECLASS="python-r1 python-utils-r1"
> > fi
> 
> see python-r1.eclass:
> """
> # Please note that python-r1 will always inherit python-utils-r1 as
> # well. Thus, all the functions defined there can be used
> # in the packages using python-r1, and there is no need ever to
> inherit # both.
> """

I don't think that hurts and usually prefer explicit inherit rather
than relying on transitive ones, but i have no strong opinion and this
can be removed

> > # @FUNCTION: ros-catkin_src_install_with_python
> > # @DESCRIPTION:
> > # Decorator around cmake-utils_src_install to ensure python scripts
> > are properly handled w.r.t. python-exec2.
> > ros-catkin_src_install_with_python() { python_export
> > PYTHON_SCRIPTDIR cmake-utils_src_install
> > if [ ! -f "${T}/.catkin_python_symlinks_generated" -a -d
> > "${D}/${PYTHON_SCRIPTDIR}" ]; then dodir /usr/bin
> > for i in "${D}/${PYTHON_SCRIPTDIR}"/* ; do
> > dosym ../lib/python-exec/python-exec2
> > "/usr/bin/${i##*/}" || die done
> > touch "${T}/.catkin_python_symlinks_generated"
> > fi
> > }
> 
> Maybe I don't understand the purpose, but this looks like a hack
> that is trying to circumvent the python eclasses.
> 
> You probably should have a look at:
> """
> # @FUNCTION: python_replicate_script
> # @USAGE: ...
> # @DESCRIPTION:
> # Copy the given script to variants for all enabled Python
> # implementations, then replace it with a symlink to the wrapper.
> #
> # All specified files must start with a 'python' shebang. A file not
> # having a matching shebang will be refused.
> """

I don't think that'll work, above code is what I came up after
talking with mgorny about how to do it.

the cmake build system will already populate PYTHON_SCRIPTDIR and
those might differ between python versions; only thing left to do is
symlinking into /usr/bin; a bit like _distutils-r1_wrap_scripts, but
for which the leading _ suggests its not public

python_replicate_script seems useful only for files ending in /usr/bin

> > 
> > # @FUNCTION: ros-catkin_src_compile
> > # @DESCRIPTION:
> > # Builds a catkin-based package.
> > ros-catkin_src_compile() {
> > if [ -n "${CATKIN_DO_PYTHON_MULTIBUILD}" ] ; then
> > python_foreach_impl cmake-utils_src_compile
> > else
> > cmake-utils_src_compile
> > fi
> > }
> > 
> 
> > 
> > # @FUNCTION: ros-catkin_src_test
> > # @DESCRIPTION:
> > # Run the tests of a catkin-based package.
> > ros-catkin_src_test() {
> > if [ -n "${CATKIN_DO_PYTHON_MULTIBUILD}" ] ; then
> > python_foreach_impl ros-catkin_src_test_internal
> > else
> > ros-catkin_src_test_internal
> > fi
> > }
> > 
> 
> > 
> > # @FUNCTION: ros-catkin_src_install
> > # @DESCRIPTION:
> > # Installs a catkin-based package.
> > ros-catkin_src_install() {
> > if [ -n "${CATKIN_DO_PYTHON_MULTIBUILD}" ] ; then
> > python_foreach_impl
> > ros-catkin_src_install_with_python else
> > cmake-utils_src_install
> > fi
> > }
> > 
> 
> I think these functions should pass arguments through to
> cmake-utils_src_* functions, so an ebuild might be able to do stuff
> like ros-catkin_src_compile -j1
> or other things if that is really needed.
> 

yep, fixed locally, thx

you should consider fixing distutils-r1 too because that's what I was
inspired by iirc :p

Alexis.