headers
Dagobert Michelsen | 1 Oct 2009 09:23
Favicon
Gravatar

[csw-maintainers] Handling of devel package splits

Hi,

I am currently packaging up a load of X11 packages. Some of them
have a load of development-stuff (headers, etc.) in them, some
only a few header files. I tend to split off the development stuff
for all of them in _devel-packages for consistency, but as we don't
have an explicit policy on this I would like to open up a small
discussion if you would consider it feasible to split even for
a few files for consistency. The alternative would be to split
on a "by case" basis where some packages with many header files
would have a devel package and some would include them in the
base package.

After a brief discussion I would like to open a poll for this.

Thoughts?

Best regards

   -- Dago
Permalink | Reply | 7 comments |
headers
Maciej (Matchek) Blizinski | 1 Oct 2009 11:15
Favicon

Re: [csw-maintainers] V8+ binaries produced by gcc on build10s

I have a relatively straightforward build:

https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/urxvt/trunk/Makefile

After building the package on build10s, I see this:

urxvt:          ELF 32-bit MSB executable SPARC32PLUS Version 1,
  V8+ Required, dynamically linked, stripped
urxvtc:         ELF 32-bit MSB executable SPARC32PLUS Version 1,
  V8+ Required, dynamically linked, stripped
urxvtd:         ELF 32-bit MSB executable SPARC32PLUS Version 1,
  V8+ Required, dynamically linked, stripped

I've added  -mno-v8plus to the compiler flags. gmake modenv says:

        CFLAGS = -O2 -pipe -mcpu=v8 -mno-v8plus -I/opt/csw/include
      CXXFLAGS = -O2 -pipe -mcpu=v8 -mno-v8plus -I/opt/csw/include

Why is gcc still producing V8+ binaries? Is there a way to influence it?

Maciej
Permalink | Reply | 4 comments |
headers
James Lee | 1 Oct 2009 11:21
Favicon

Re: [csw-maintainers] V8+ binaries produced by gcc on build10s

On 01/10/09, 10:15:32, Maciej "(Matchek)" Blizinski <maciej@...>
wrote regarding Re: [csw-maintainers] V8+ binaries produced by gcc on
build10s:

> After building the package on build10s, I see this:

> urxvt:          ELF 32-bit MSB executable SPARC32PLUS Version 1,
>   V8+ Required, dynamically linked, stripped

> Why is gcc still producing V8+ binaries?

Solaris 10 is at least v8plus so it's the right thing to do anyway.

James.
Permalink | Reply | 0 comments |
headers
Dagobert Michelsen | 1 Oct 2009 11:35
Favicon
Gravatar

Re: [csw-maintainers] Handling of devel package splits

Hi,

Am 01.10.2009 um 09:23 schrieb Dagobert Michelsen:
> I am currently packaging up a load of X11 packages. Some of them
> have a load of development-stuff (headers, etc.) in them, some
> only a few header files. I tend to split off the development stuff
> for all of them in _devel-packages for consistency, but as we don't
> have an explicit policy on this I would like to open up a small
> discussion if you would consider it feasible to split even for
> a few files for consistency. The alternative would be to split
> on a "by case" basis where some packages with many header files
> would have a devel package and some would include them in the
> base package.
>
> After a brief discussion I would like to open a poll for this.

As we already had some discussion on IRC, here is the poll:
   <http://doodle.com/2e8eakee997gtmmv>

Best regards

   -- Dago
Permalink | Reply | 2 comments |
headers
Dagobert Michelsen | 1 Oct 2009 11:40
Favicon
Gravatar

Re: [csw-maintainers] V8+ binaries produced by gcc on build10s


Am 01.10.2009 um 11:15 schrieb Maciej (Matchek) Blizinski:

> I have a relatively straightforward build:
>
> https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/urxvt/trunk/Makefile
>
> After building the package on build10s, I see this:
>
> urxvt:          ELF 32-bit MSB executable SPARC32PLUS Version 1,
>  V8+ Required, dynamically linked, stripped
> urxvtc:         ELF 32-bit MSB executable SPARC32PLUS Version 1,
>  V8+ Required, dynamically linked, stripped
> urxvtd:         ELF 32-bit MSB executable SPARC32PLUS Version 1,
>  V8+ Required, dynamically linked, stripped
>
> I've added  -mno-v8plus to the compiler flags. gmake modenv says:
>
>        CFLAGS = -O2 -pipe -mcpu=v8 -mno-v8plus -I/opt/csw/include
>      CXXFLAGS = -O2 -pipe -mcpu=v8 -mno-v8plus -I/opt/csw/include
>
> Why is gcc still producing V8+ binaries? Is there a way to influence  
> it?

This seems like a bug. Is there something on the GCC lists?

Best regards

   -- Dago
(Continue reading)

Permalink | Reply | 2 comments |
headers
Dagobert Michelsen | 1 Oct 2009 11:45
Favicon
Gravatar

Re: [csw-maintainers] V8+ binaries produced by gcc on build10s

Hi Maciej,

Am 01.10.2009 um 11:40 schrieb Dagobert Michelsen:
> Am 01.10.2009 um 11:15 schrieb Maciej (Matchek) Blizinski:
>
>> I have a relatively straightforward build:
>>
>> https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/urxvt/trunk/Makefile
>>
>> After building the package on build10s, I see this:
>>
>> urxvt:          ELF 32-bit MSB executable SPARC32PLUS Version 1,
>> V8+ Required, dynamically linked, stripped
>> urxvtc:         ELF 32-bit MSB executable SPARC32PLUS Version 1,
>> V8+ Required, dynamically linked, stripped
>> urxvtd:         ELF 32-bit MSB executable SPARC32PLUS Version 1,
>> V8+ Required, dynamically linked, stripped
>>
>> I've added  -mno-v8plus to the compiler flags. gmake modenv says:
>>
>>       CFLAGS = -O2 -pipe -mcpu=v8 -mno-v8plus -I/opt/csw/include
>>     CXXFLAGS = -O2 -pipe -mcpu=v8 -mno-v8plus -I/opt/csw/include
>>
>> Why is gcc still producing V8+ binaries? Is there a way to  
>> influence it?
>
> This seems like a bug. Is there something on the GCC lists?

It looks like the compilation is ok, but as the provided libs in  
Solaris 10
(Continue reading)

Permalink | Reply | 1 comment |
headers
James Lee | 1 Oct 2009 11:57
Favicon

Re: [csw-maintainers] V8+ binaries produced by gcc on build10s

On 01/10/09, 10:45:08, Dagobert Michelsen <dam@...> wrote regarding
Re: [csw-maintainers] V8+ binaries produced by gcc on build10s:

> >>
> >> I've added  -mno-v8plus to the compiler flags. gmake modenv says:
> >>
> >>       CFLAGS = -O2 -pipe -mcpu=v8 -mno-v8plus -I/opt/csw/include
> >>     CXXFLAGS = -O2 -pipe -mcpu=v8 -mno-v8plus -I/opt/csw/include
> >>
> >> Why is gcc still producing V8+ binaries? Is there a way to
> >> influence it?
> >
> > This seems like a bug. Is there something on the GCC lists?

> It looks like the compilation is ok, but as the provided libs in
> Solaris 10
> are sparcv8plus the resulting binary is also:

> rxvtd:          ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+
> Required, dynamically linked, not stripped
> rxvtd.o:        ELF 32-bit MSB relocatable SPARC Version 1

Because Solaris 10 is.  Don't target a processor that can't run the
OS.  Set the compile flags to target what Solaris 10 will run.

James.
Permalink | Reply | 0 comments |
headers
James Lee | 1 Oct 2009 11:53
Favicon

Re: [csw-maintainers] Handling of devel package splits

On 01/10/09, 10:35:41, Dagobert Michelsen <dam@...> wrote regarding
Re: [csw-maintainers] Handling of devel package splits:

> Am 01.10.2009 um 09:23 schrieb Dagobert Michelsen:
> > I am currently packaging up a load of X11 packages. Some of them
> > have a load of development-stuff (headers, etc.) in them, some
> > only a few header files. I tend to split off the development stuff
> > for all of them in _devel-packages for consistency, but as we don't
> > have an explicit policy on this I would like to open up a small
> > discussion if you would consider it feasible to split even for
> > a few files for consistency. The alternative would be to split
> > on a "by case" basis where some packages with many header files
> > would have a devel package and some would include them in the
> > base package.
> >
> > After a brief discussion I would like to open a poll for this.

> As we already had some discussion on IRC, here is the poll:
>    <http://doodle.com/2e8eakee997gtmmv>

You are missing an option.

If foo is a distribution, I install foo and I get CSWfoo with all
foo's files.  How that is split doesn't matter, eg, comprises an
rt sub package, is split into arch neutral and binary.

Package depends can bring in the rt only but I think that installing
a product by name should install that product, a 1:1 correspondence
between upstream product and top level package with the same name.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Philip Brown | 1 Oct 2009 18:16
Favicon

Re: [csw-maintainers] Handling of devel package splits

On Thu, Oct 1, 2009 at 2:35 AM, Dagobert Michelsen <dam@...> wrote:
>
>> After a brief discussion I would like to open a poll for this.
>
> As we already had some discussion on IRC, here is the poll:
>  <http://doodle.com/2e8eakee997gtmmv>
>

I think this is a very unfair way to handle things. Discussions for
official packaging issues, should either be done on the mailing list,
or at MINIMUM, the full irc logs need to be posted.

I do not see any reference to irc logs.
Permalink | Reply | 0 comments |
headers
Philip Brown | 1 Oct 2009 18:29
Favicon

Re: [csw-maintainers] Handling of devel package splits

The poll is inadequately described. For such a critical, major policy
change such as this, you must be more explicit.

The poll should describe what "split off devel" means.

First, (presuming this is your intent), you should explicitly say,
"MUST split off _devel".
then you need to describe everything that should go in there.

ALSO, you did not adequately describe potential justifications for
when things should be split off vs not, for the "case by case basis".

For example, the criteria that I personally use, are the following:

a) Any time a maintainer wishes to provide a static library, it should
be done in a separate _devel package
b) when there are excessive amounts of development specific
documentation, that belong more in a
  _devel package, than a _doc package. (eg: if there is substantial
user documentation, but also substantial development documentation),
it MAY be a good idea to split off the devel docs.
c) when there's a bunch of development-useful-only tools, it MAY be
useful to split them off.

Generally speaking, when splitting off devel stuff saves 20% of the
package, or a megabyte or more of download size.

HOWEVER, none of the above to me are really important, if the _devel
package is going to be something silly like 20k in size. or if a
single combined package is going to be "small" anyway.
(Continue reading)

Permalink | Reply | 3 comments |

Gmane