[csw-maintainers] Handling of devel package splits

[Dagobert Michelsen]

Am 04.10.2009 um 11:37 schrieb Sebastian Kayser:

> Dagobert Michelsen wrote:
>> I would like to proceed on the splitting of devel packages as a  
>> package
>> of mine is pending release whether the decision on this topic.
>>
>> The current poll is
>> - 5 maintainers for "split off devel"
>> - 1 maintainer for "decide on case-by-case"
>>
>> Does anyone feel that there is need for more discussion?
>>
>> Has anyone (especially those who have voted) understood that the  
>> split
>> will then be mandatory for package releases?
>
> Do we have a written out wording for what is subject to the _devel  
> split
> then?

Like this:

"Files related to developers must be split off in a separate developer  
package.
Exceptions can be made when the primary target audience of the package  
are developers.
When the base package is named CSW<pkg> with the catalog name <pkg>  
the developer
package must be name CSW<pkg>devel with the catalog name <pkg>_devel.  
The developer
package should contain
   bin/*-config
   *.a (static libs, if at all included)
   pkgconfig/*
   include/* (header files)
   aclocal/* (for autoconf)
   man1/*-config.1* (man pages for *-config)
   man3/* (man pages for header files)
It may contain other files not related to the normal functionality of  
the package
only relevant for compiling or building programs not usually done by  
the user.
This means that for packages primarily focused on developers like Perl  
do not
have a separate devel package as the base module itself is already for  
developers.
The developer package for Perl may include the libperl.a static lib  
only relevant
when building new packages with an embedded Perl."

>> Sebastian, would you be willing to unify the bugs and introduce
>> the "bugs-package-link" you suggested once we have clarified this
>> issue?
>
>  http://bugs.opencsw.org/<pkgname>
>
> Yup, will develop this on my local box and then need Ihsan's help to
> implement it on the www box. What do you mean by "unify"?

When we are going towards splitting up packages the package list in  
Mantis gets
even longer and it is already very long. As the bugs are usually  
related to
upstream packages it is feasible to put all bugs for packages produced  
for an
upstream package together under its garname instead of having separate  
buglists
for each individual package. That means you would e. g. have just  
"openssl"
instead of "openssl_rt", "openssl_devel", "openssl_doc" etc. The  
change should
only affect Mantis. The section in Mantis should then be accessed only  
with
the URL syntax you described, so the abstraction is done at only one  
place.
You can get the list of packages produced by a GAR description with
   gmake pkglist
so the information for the mapping table is in there.


Best regards

   -- Dago