[general] JPackage - new opportunity for Harmony?

[Alexey Petrenko <al...@gmail.com>]

One of the Tomcat developers has pointed me to JPackage project[1].
This project is distributing a rather big number of Java based
projects for Linux in common way.
It also distributes JDKs. Now they have only Sun JDK in their list.

I think it would be good for Harmony to try to participate in this project.

I've wrote a letter to JPackage discussion list and has received few
favorable responses.

So we probably should create JPackage compatible rpm of Harmony and
suggest it for inclusion.

The good thing that we can demonstrate all the benefits of Harmony's
modularity by creating a set of rpms and let the user choose which
parts of Harmony he really needs.
Not so good thing is that we need significant changes to Harmony's
build system to be fully compatible with building Harmony from source
RPM. Which is probably not a requirement for JPackage but a good form
for Linux community.

However we can start from simple binary rpm based on Harmony M3 for example.

Thoughts? Objections?

Thanks in advance.

SY, Alexey

1. http://www.jpackage.org

Re: [general] JPackage - new opportunity for Harmony?

[Xiao-Feng Li <xi...@gmail.com>]

On Nov 15, 2007 12:57 AM, Alexey Petrenko <al...@gmail.com> wrote:
> One of the Tomcat developers has pointed me to JPackage project[1].
> This project is distributing a rather big number of Java based
> projects for Linux in common way.
> It also distributes JDKs. Now they have only Sun JDK in their list.
>
> I think it would be good for Harmony to try to participate in this project.
>
> I've wrote a letter to JPackage discussion list and has received few
> favorable responses.
>
> So we probably should create JPackage compatible rpm of Harmony and
> suggest it for inclusion.
>
> The good thing that we can demonstrate all the benefits of Harmony's
> modularity by creating a set of rpms and let the user choose which
> parts of Harmony he really needs.
> Not so good thing is that we need significant changes to Harmony's
> build system to be fully compatible with building Harmony from source
> RPM. Which is probably not a requirement for JPackage but a good form
> for Linux community.
>
> However we can start from simple binary rpm based on Harmony M3 for example.
>
> Thoughts? Objections?

Strongly support the proposal. Thanks.

> Thanks in advance.
>
> SY, Alexey
>
> 1. http://www.jpackage.org
>



-- 
http://xiao-feng.blogspot.com

Re: [general] JPackage - new opportunity for Harmony?

[Stepan Mishura <st...@gmail.com>]

On 11/15/07, Alexey Varlamov <al...@gmail.com> wrote:
> 2007/11/15, Mark Hindess <ma...@googlemail.com>:
<SNIP>
> > > Not so good thing is that we need significant changes to Harmony's
> > > build system to be fully compatible with building Harmony from source
> > > RPM. Which is probably not a requirement for JPackage but a good form
> > > for Linux community.
> >
> > I assume you mean the requirements not to include external
> > libraries/jars?  I've been thinking about this problem a little and am
> > keen to move things forward.
> >
> > I added the hy.local.zlib option to remove one such issue but there
> > are many more in terms of jars/libs/fonts/etc that still need to be
> > addressed.  I don't really like the hy.local.zlib option and think that
> > really we need to (re)design the way we handle dependencies consistently
> > across classlib/jdktools/drlvm with support for local/ system and
> > remote/downloaded dependencies.  (The recent icu issue is a good example
> > of the problems that should be avoided by having an accurate, implicit,
> > consistent dependency implementation.)
>
> Agree, this is a real nag. The common_resources aren't work as
> intended, every module is dancing differently. BTW, the BTI solves the
> same problem once again and I guess Stepan is not quite happy in that
> - shouldn't there be a reusable solution?
>

I'd not say that I'm unhappy with it. Sure, there are serveral things
to be improved but it does required work as expected. I even think
that it may be reused by classlib/drlvm/jdktools at some stage :-)

-Stepan.

Re: [general] JPackage - new opportunity for Harmony?

[Alexey Varlamov <al...@gmail.com>]

2007/11/15, Mark Hindess <ma...@googlemail.com>:
>
> On 14 November 2007 at 19:57, "Alexey Petrenko"
> <al...@gmail.com> wrote:
> > One of the Tomcat developers has pointed me to JPackage project[1].
> > This project is distributing a rather big number of Java based
> > projects for Linux in common way.  It also distributes JDKs. Now they
> > have only Sun JDK in their list.
> >
> > I think it would be good for Harmony to try to participate in this
> > project.
> >
> > I've wrote a letter to JPackage discussion list and has received few
> > favorable responses.
>
> Excellent.
Nice, indeed.

> > So we probably should create JPackage compatible rpm of Harmony and
> > suggest it for inclusion.
> >
> > The good thing that we can demonstrate all the benefits of Harmony's
> > modularity by creating a set of rpms and let the user choose which
> > parts of Harmony he really needs.
> >
> > Not so good thing is that we need significant changes to Harmony's
> > build system to be fully compatible with building Harmony from source
> > RPM. Which is probably not a requirement for JPackage but a good form
> > for Linux community.
>
> I assume you mean the requirements not to include external
> libraries/jars?  I've been thinking about this problem a little and am
> keen to move things forward.
>
> I added the hy.local.zlib option to remove one such issue but there
> are many more in terms of jars/libs/fonts/etc that still need to be
> addressed.  I don't really like the hy.local.zlib option and think that
> really we need to (re)design the way we handle dependencies consistently
> across classlib/jdktools/drlvm with support for local/ system and
> remote/downloaded dependencies.  (The recent icu issue is a good example
> of the problems that should be avoided by having an accurate, implicit,
> consistent dependency implementation.)

Agree, this is a real nag. The common_resources aren't work as
intended, every module is dancing differently. BTW, the BTI solves the
same problem once again and I guess Stepan is not quite happy in that
- shouldn't there be a reusable solution?

>
> > However we can start from simple binary rpm based on Harmony M3 for
> > example.
> >
> > Thoughts? Objections?
>
> I don't really use rpm-based distros but I have in the past and a
> reasonable knowledge of spec files.  I'm happy to help.
>
> Regards,
>  Mark.
>
>
>

Re: [general] JPackage - new opportunity for Harmony?

[Tim Ellison <t....@gmail.com>]

Mark Hindess wrote:
<snip>
> Geir did have a point but I never understood why we needed static
> versions of jpeg, lcms, and png but not X11, Xft, Xau, Xdmcp,
> fontconfig, freetype, Xrender, expat, libc, etc.  Particularly when you
> consider that the API for jpeg has been stable for years and many of the
> others have not.

This is the key point for me -- it depends upon how stable the
dependencies are in each case; while it may be safe to refer to some
dynamically others we will choose to carry with us statically.

<snip>

> Incidentally, I'd also like to push the dependency information down to
> the modules.  At the moment, if you run:
> 
>   ant -Dbuild.module=luni build-java
> 
> I think the build still looks up (checks at the moment) libpng/jpeg/lcms
> headers etc.  This really should be handled by the awt module (and IIRC
> imageio module for libjpeg).  I like the idea of having dependencies
> specified within the modules (just as we do in the OSGI headers of the
> MANIFESTs for java code).

+1

Regards,
Tim

Re: [general] JPackage - new opportunity for Harmony?

[Alexey Petrenko <al...@gmail.com>]

2007/11/16, Mark Hindess <ma...@googlemail.com>:
>
> On 15 November 2007 at 23:33, Gregory Shimansky <gs...@apache.org> wrote:
> > Mark Hindess wrote:
> > > On 14 November 2007 at 19:57, "Alexey Petrenko"
> > > <al...@gmail.com> wrote:
> > >> One of the Tomcat developers has pointed me to JPackage project[1].
> > >> This project is distributing a rather big number of Java based
> > >> projects for Linux in common way.  It also distributes JDKs. Now they
> > >> have only Sun JDK in their list.
> > >>
> > >> I think it would be good for Harmony to try to participate in this
> > >> project.
> > >>
> > >> I've wrote a letter to JPackage discussion list and has received few
> > >> favorable responses.
> > >
> > > Excellent.
> > >
> > >> So we probably should create JPackage compatible rpm of Harmony and
> > >> suggest it for inclusion.
> > >>
> > >> The good thing that we can demonstrate all the benefits of Harmony's
> > >> modularity by creating a set of rpms and let the user choose which
> > >> parts of Harmony he really needs.
> > >>
> > >> Not so good thing is that we need significant changes to Harmony's
> > >> build system to be fully compatible with building Harmony from source
> > >> RPM. Which is probably not a requirement for JPackage but a good form
> > >> for Linux community.
> > >
> > > I assume you mean the requirements not to include external
> > > libraries/jars?  I've been thinking about this problem a little and
> > > am keen to move things forward.
> > >
> > > I added the hy.local.zlib option to remove one such issue but there
> > > are many more in terms of jars/libs/fonts/etc that still need to be
> > > addressed.  I don't really like the hy.local.zlib option and think
> > > that really we need to (re)design the way we handle dependencies
> > > consistently across classlib/jdktools/drlvm with support for local/
> > > system and remote/downloaded dependencies.  (The recent icu issue is
> > > a good example of the problems that should be avoided by having an
> > > accurate, implicit, consistent dependency implementation.)
> >
> > I've argued with Geir since the beginning that I'd like to see
> > Harmony using dependencies from the installed distros as must as
> > it is possible while Geir insisted that we link statically when we
> > can. Things played in the favor of my POV a bit when it appeared that
> > on x86_64 linking statically with jpeg, png and lcms simply doesn't
> > work as these packages built statically by distros are not built as
> > relocatable code, and we don't want to distribute our own versions of
> > jpeg, png and lcms binaries.
>
> Of course, we do for windows so we could distribute -fpic versions for
> the other platforms too.  But I agree we don't want to.
>
> > Geir however has got a point since only a binary JRE is certified as a
> > Java(TM). For example Sun distributes its JRE with the above libraries
> > linked statically.
>
> Geir did have a point but I never understood why we needed static
> versions of jpeg, lcms, and png but not X11, Xft, Xau, Xdmcp,
> fontconfig, freetype, Xrender, expat, libc, etc.  Particularly when you
> consider that the API for jpeg has been stable for years and many of the
> others have not.
>
> I assume that we'd will need to specify the environment certified binary
> JREs are certified on so I don't see how adding a few more things to the
> description of the environment is a big problem.
>
> > The list of Harmony dependencies goes much farther than just graphical
> > libraries. And handling them should be more flexible than it is done
> > currently. Why do you not like hy.local.zlib? Something like that
> > I've been thinking about, making more packages to be taken from local
> > installation to allow tighter integration with packages that distros
> > create.
>
> I don't like it because I think this detail should be hidden by whatever
> abstraction we create to handle dependencies.  For example, I think we
> should just query the dependency abstraction in much the same way that
> other systems query pkg-config.  For example, on my machine I can do:
>
>   pkg-config --cflags libpng
>
> and get the answer:
>
>   -I/usr/include/libpng12
>
> and:
>
>   pkg-config --libs libpng
>
> and get the answer:
>
>   -lpng12
>
> If I so wished (I don't it is a terrible idea) then I could modify the
> configuration so that the answer for --libs was /usr/lib/libpng.a and
> everything I built from then on would use the static library instead.
> But the builds don't need to care about these detail.
>
> At the moment, I think extending hy.local.* to cover other dependencies
> will start to get ugly pretty quickly.
>
> Having said that, zlib is a bit of an odd one since we also change the
> name (and explicitly load it in drlvm) so perhaps this one is necessary.
>
> Incidentally, I'd also like to push the dependency information down to
> the modules.  At the moment, if you run:
>
>   ant -Dbuild.module=luni build-java
>
> I think the build still looks up (checks at the moment) libpng/jpeg/lcms
> headers etc.  This really should be handled by the awt module (and IIRC
> imageio module for libjpeg).  I like the idea of having dependencies
> specified within the modules (just as we do in the OSGI headers of the
> MANIFESTs for java code).
Yes! This would be really good!

SY, Alexey

Re: [general] JPackage - new opportunity for Harmony?

[Mark Hindess <ma...@googlemail.com>]

On 15 November 2007 at 23:33, Gregory Shimansky <gs...@apache.org> wrote:
> Mark Hindess wrote:
> > On 14 November 2007 at 19:57, "Alexey Petrenko"
> > <al...@gmail.com> wrote:
> >> One of the Tomcat developers has pointed me to JPackage project[1].
> >> This project is distributing a rather big number of Java based
> >> projects for Linux in common way.  It also distributes JDKs. Now they
> >> have only Sun JDK in their list.
> >>
> >> I think it would be good for Harmony to try to participate in this
> >> project.
> >>
> >> I've wrote a letter to JPackage discussion list and has received few
> >> favorable responses.
> > 
> > Excellent.
> > 
> >> So we probably should create JPackage compatible rpm of Harmony and
> >> suggest it for inclusion.
> >>
> >> The good thing that we can demonstrate all the benefits of Harmony's
> >> modularity by creating a set of rpms and let the user choose which
> >> parts of Harmony he really needs.
> >>
> >> Not so good thing is that we need significant changes to Harmony's
> >> build system to be fully compatible with building Harmony from source
> >> RPM. Which is probably not a requirement for JPackage but a good form
> >> for Linux community.
> > 
> > I assume you mean the requirements not to include external
> > libraries/jars?  I've been thinking about this problem a little and
> > am keen to move things forward.
> >
> > I added the hy.local.zlib option to remove one such issue but there
> > are many more in terms of jars/libs/fonts/etc that still need to be
> > addressed.  I don't really like the hy.local.zlib option and think
> > that really we need to (re)design the way we handle dependencies
> > consistently across classlib/jdktools/drlvm with support for local/
> > system and remote/downloaded dependencies.  (The recent icu issue is
> > a good example of the problems that should be avoided by having an
> > accurate, implicit, consistent dependency implementation.)
>
> I've argued with Geir since the beginning that I'd like to see
> Harmony using dependencies from the installed distros as must as
> it is possible while Geir insisted that we link statically when we
> can. Things played in the favor of my POV a bit when it appeared that
> on x86_64 linking statically with jpeg, png and lcms simply doesn't
> work as these packages built statically by distros are not built as
> relocatable code, and we don't want to distribute our own versions of
> jpeg, png and lcms binaries.

Of course, we do for windows so we could distribute -fpic versions for 
the other platforms too.  But I agree we don't want to.

> Geir however has got a point since only a binary JRE is certified as a 
> Java(TM). For example Sun distributes its JRE with the above libraries 
> linked statically.

Geir did have a point but I never understood why we needed static
versions of jpeg, lcms, and png but not X11, Xft, Xau, Xdmcp,
fontconfig, freetype, Xrender, expat, libc, etc.  Particularly when you
consider that the API for jpeg has been stable for years and many of the
others have not.

I assume that we'd will need to specify the environment certified binary
JREs are certified on so I don't see how adding a few more things to the
description of the environment is a big problem.

> The list of Harmony dependencies goes much farther than just graphical
> libraries. And handling them should be more flexible than it is done
> currently. Why do you not like hy.local.zlib? Something like that
> I've been thinking about, making more packages to be taken from local
> installation to allow tighter integration with packages that distros
> create.

I don't like it because I think this detail should be hidden by whatever
abstraction we create to handle dependencies.  For example, I think we
should just query the dependency abstraction in much the same way that
other systems query pkg-config.  For example, on my machine I can do:

  pkg-config --cflags libpng

and get the answer:

  -I/usr/include/libpng12  

and:

  pkg-config --libs libpng

and get the answer:

  -lpng12  

If I so wished (I don't it is a terrible idea) then I could modify the
configuration so that the answer for --libs was /usr/lib/libpng.a and
everything I built from then on would use the static library instead.
But the builds don't need to care about these detail.

At the moment, I think extending hy.local.* to cover other dependencies
will start to get ugly pretty quickly.

Having said that, zlib is a bit of an odd one since we also change the
name (and explicitly load it in drlvm) so perhaps this one is necessary.

Incidentally, I'd also like to push the dependency information down to
the modules.  At the moment, if you run:

  ant -Dbuild.module=luni build-java

I think the build still looks up (checks at the moment) libpng/jpeg/lcms
headers etc.  This really should be handled by the awt module (and IIRC
imageio module for libjpeg).  I like the idea of having dependencies
specified within the modules (just as we do in the OSGI headers of the
MANIFESTs for java code).

Regards,
 Mark.

Re: [general] JPackage - new opportunity for Harmony?

[Gregory Shimansky <gs...@apache.org>]

Mark Hindess wrote:
> On 14 November 2007 at 19:57, "Alexey Petrenko"
> <al...@gmail.com> wrote:
>> One of the Tomcat developers has pointed me to JPackage project[1].
>> This project is distributing a rather big number of Java based
>> projects for Linux in common way.  It also distributes JDKs. Now they
>> have only Sun JDK in their list.
>>
>> I think it would be good for Harmony to try to participate in this
>> project.
>>
>> I've wrote a letter to JPackage discussion list and has received few
>> favorable responses.
> 
> Excellent.
> 
>> So we probably should create JPackage compatible rpm of Harmony and
>> suggest it for inclusion.
>>
>> The good thing that we can demonstrate all the benefits of Harmony's
>> modularity by creating a set of rpms and let the user choose which
>> parts of Harmony he really needs.
>>
>> Not so good thing is that we need significant changes to Harmony's
>> build system to be fully compatible with building Harmony from source
>> RPM. Which is probably not a requirement for JPackage but a good form
>> for Linux community.
> 
> I assume you mean the requirements not to include external
> libraries/jars?  I've been thinking about this problem a little and am
> keen to move things forward.
> 
> I added the hy.local.zlib option to remove one such issue but there
> are many more in terms of jars/libs/fonts/etc that still need to be
> addressed.  I don't really like the hy.local.zlib option and think that
> really we need to (re)design the way we handle dependencies consistently
> across classlib/jdktools/drlvm with support for local/ system and
> remote/downloaded dependencies.  (The recent icu issue is a good example
> of the problems that should be avoided by having an accurate, implicit,
> consistent dependency implementation.)

I've argued with Geir since the beginning that I'd like to see Harmony 
using dependencies from the installed distros as must as it is possible 
while Geir insisted that we link statically when we can. Things played 
in the favor of my POV a bit when it appeared that on x86_64 linking 
statically with jpeg, png and lcms simply doesn't work as these packages 
built statically by distros are not built as relocatable code, and we 
don't want to distribute our own versions of jpeg, png and lcms binaries.

Geir however has got a point since only a binary JRE is certified as a 
Java(TM). For example Sun distributes its JRE with the above libraries 
linked statically.

The list of Harmony dependencies goes much farther than just graphical 
libraries. And handling them should be more flexible than it is done 
currently. Why do you not like hy.local.zlib? Something like that I've 
been thinking about, making more packages to be taken from local 
installation to allow tighter integration with packages that distros create.

>> However we can start from simple binary rpm based on Harmony M3 for
>> example.
>>
>> Thoughts? Objections?
> 
> I don't really use rpm-based distros but I have in the past and a
> reasonable knowledge of spec files.  I'm happy to help.
> 
> Regards,
>  Mark.
> 
> 
> 


-- 
Gregory

Re: [general] JPackage - new opportunity for Harmony?

[Gregory Shimansky <gs...@apache.org>]

Alexey Petrenko wrote:
> 2007/11/15, Mark Hindess <ma...@googlemail.com>:
>> On 14 November 2007 at 19:57, "Alexey Petrenko"
>> <al...@gmail.com> wrote:
>>> One of the Tomcat developers has pointed me to JPackage project[1].
>>> This project is distributing a rather big number of Java based
>>> projects for Linux in common way.  It also distributes JDKs. Now they
>>> have only Sun JDK in their list.
>>>
>>> I think it would be good for Harmony to try to participate in this
>>> project.
>>>
>>> I've wrote a letter to JPackage discussion list and has received few
>>> favorable responses.
>> Excellent.
>>
>>> So we probably should create JPackage compatible rpm of Harmony and
>>> suggest it for inclusion.
>>>
>>> The good thing that we can demonstrate all the benefits of Harmony's
>>> modularity by creating a set of rpms and let the user choose which
>>> parts of Harmony he really needs.
>>>
>>> Not so good thing is that we need significant changes to Harmony's
>>> build system to be fully compatible with building Harmony from source
>>> RPM. Which is probably not a requirement for JPackage but a good form
>>> for Linux community.
>> I assume you mean the requirements not to include external
>> libraries/jars?  I've been thinking about this problem a little and am
>> keen to move things forward.
> Yes, exactly. And we also need to remove build of dependencies from
> DRLVM build for example.

+1 here

APR, log4cxx are provided by many distros already. This, however, is not 
true for windows.

>> I added the hy.local.zlib option to remove one such issue but there
>> are many more in terms of jars/libs/fonts/etc that still need to be
>> addressed.  I don't really like the hy.local.zlib option and think that
>> really we need to (re)design the way we handle dependencies consistently
>> across classlib/jdktools/drlvm with support for local/ system and
>> remote/downloaded dependencies.  (The recent icu issue is a good example
>> of the problems that should be avoided by having an accurate, implicit,
>> consistent dependency implementation.)
>>
>>> However we can start from simple binary rpm based on Harmony M3 for
>>> example.
>>>
>>> Thoughts? Objections?
>> I don't really use rpm-based distros but I have in the past and a
>> reasonable knowledge of spec files.  I'm happy to help.
> Great!. I think we should start from simple binary RPM based on M3 build.
> 
> SY, Alexey
> 


-- 
Gregory

Re: [general] JPackage - new opportunity for Harmony?

[Alexey Petrenko <al...@gmail.com>]

2007/11/15, Mark Hindess <ma...@googlemail.com>:
>
> On 14 November 2007 at 19:57, "Alexey Petrenko"
> <al...@gmail.com> wrote:
> > One of the Tomcat developers has pointed me to JPackage project[1].
> > This project is distributing a rather big number of Java based
> > projects for Linux in common way.  It also distributes JDKs. Now they
> > have only Sun JDK in their list.
> >
> > I think it would be good for Harmony to try to participate in this
> > project.
> >
> > I've wrote a letter to JPackage discussion list and has received few
> > favorable responses.
>
> Excellent.
>
> > So we probably should create JPackage compatible rpm of Harmony and
> > suggest it for inclusion.
> >
> > The good thing that we can demonstrate all the benefits of Harmony's
> > modularity by creating a set of rpms and let the user choose which
> > parts of Harmony he really needs.
> >
> > Not so good thing is that we need significant changes to Harmony's
> > build system to be fully compatible with building Harmony from source
> > RPM. Which is probably not a requirement for JPackage but a good form
> > for Linux community.
> I assume you mean the requirements not to include external
> libraries/jars?  I've been thinking about this problem a little and am
> keen to move things forward.
Yes, exactly. And we also need to remove build of dependencies from
DRLVM build for example.

> I added the hy.local.zlib option to remove one such issue but there
> are many more in terms of jars/libs/fonts/etc that still need to be
> addressed.  I don't really like the hy.local.zlib option and think that
> really we need to (re)design the way we handle dependencies consistently
> across classlib/jdktools/drlvm with support for local/ system and
> remote/downloaded dependencies.  (The recent icu issue is a good example
> of the problems that should be avoided by having an accurate, implicit,
> consistent dependency implementation.)
>
> > However we can start from simple binary rpm based on Harmony M3 for
> > example.
> >
> > Thoughts? Objections?
> I don't really use rpm-based distros but I have in the past and a
> reasonable knowledge of spec files.  I'm happy to help.
Great!. I think we should start from simple binary RPM based on M3 build.

SY, Alexey

Re: [general] JPackage - new opportunity for Harmony?

[Mark Hindess <ma...@googlemail.com>]

On 14 November 2007 at 19:57, "Alexey Petrenko"
<al...@gmail.com> wrote:
> One of the Tomcat developers has pointed me to JPackage project[1].
> This project is distributing a rather big number of Java based
> projects for Linux in common way.  It also distributes JDKs. Now they
> have only Sun JDK in their list.
>
> I think it would be good for Harmony to try to participate in this
> project.
>
> I've wrote a letter to JPackage discussion list and has received few
> favorable responses.

Excellent.

> So we probably should create JPackage compatible rpm of Harmony and
> suggest it for inclusion.
>
> The good thing that we can demonstrate all the benefits of Harmony's
> modularity by creating a set of rpms and let the user choose which
> parts of Harmony he really needs.
>
> Not so good thing is that we need significant changes to Harmony's
> build system to be fully compatible with building Harmony from source
> RPM. Which is probably not a requirement for JPackage but a good form
> for Linux community.

I assume you mean the requirements not to include external
libraries/jars?  I've been thinking about this problem a little and am
keen to move things forward.

I added the hy.local.zlib option to remove one such issue but there
are many more in terms of jars/libs/fonts/etc that still need to be
addressed.  I don't really like the hy.local.zlib option and think that
really we need to (re)design the way we handle dependencies consistently
across classlib/jdktools/drlvm with support for local/ system and
remote/downloaded dependencies.  (The recent icu issue is a good example
of the problems that should be avoided by having an accurate, implicit,
consistent dependency implementation.)

> However we can start from simple binary rpm based on Harmony M3 for
> example.
>
> Thoughts? Objections?

I don't really use rpm-based distros but I have in the past and a
reasonable knowledge of spec files.  I'm happy to help.

Regards,
 Mark.