Already answered this, so just for the record, see
the 1st bullet under "spec file changes" in the Code Review
Guidelines at 
http://www.opensolaris.org/os/project/jds/documents/code_review/

You are right, we didn't follow these rules consistently.

Laca

On Wed, 2006-10-25 at 11:54 +0100, Calum Benson wrote:
> While we're at it, can somebody clarify (and can we then enforce) the  
> policy about which patches should go in spec-files/patches, and which  
> in spec-files/Solaris/patches?
> 
> Last time I asked Laca, what he told me seemed to be rather different  
> from how some people were using it (and the fact that we're only  
> actively developing for Solaris anyway at the moment probably just  
> adds to the confusion...)
> 
> Cheeri,
> Calum.
> 
> On 25 Oct 2006, at 03:47, Glynn Foster wrote:
> 
> > Hey,
> >
> > I'd like to propose a full clean up of spec-files, deleting  
> > anything that isn't
> > absolutely critical to our Solaris build. This will involve the  
> > removal in the
> > following order -
> >
> >     o Linux spec files that aren't referenced in Solaris spec files
> >     o Patches that aren't referenced anywhere
> >     o Extra sources that aren't referenced anywhere
> >
> > I'll probably separate those steps in different mails.
> >
> > Here's the analysis. Please review, thanks!
> >
> >
> > Glynn
> >
> >
> > bash-3.00$ ./check_unused.sh -linux-only
> >
> >   blueprint-cursor.spec
> >
> >   We're not currently shipping cursor themes, though we may want to  
> > in the
> >   future. Alan said libXcursor is likely to be in the 7.2 release  
> > of Xorg,
> >   so we may want to consider our options then.
> >   Recommendation: Remove for now, and revisit
> >
> >
> >   fontconfig.spec
> >
> >   Fontconfig is being shipped as part of the X consolidation. We need
> >   to work out a process for non-JDS consolidation requirements  
> > (like HAL)
> >   should we require newer versions in the future.
> >   Recommendation: Remove
> >
> >
> >   libgnomecups.spec
> >   gnome-cups-manager.spec
> >
> >   CUPS is not a default part of Solaris right now, and the  
> > direction seems
> >   clearly focused on PAPI development, and the new GTK+ printing  
> > APIs. I
> >   don't see a need for this in the future.
> >   Recommendation: Remove
> >
> >
> >   gnome-nettool.spec
> >
> >   Nettool isn't what I would personally call a useful tool. It's  
> > basically a
> >   wrapper around things like ping, netstat, which I would classify  
> > as 'power
> >   user' utilities. Likely to be very Linux specific, and not  
> > something that we
> >   desperately need to ship.
> >   Recommendation: Remove for now, and revisit according to the  
> > Desktop Gaps
> >                   Analysis
> >
> >
> >   gnomemeeting.spec
> >   openh323.spec
> >   pwlib.spec
> >
> >   This is an easy one. It should have been removed once ekiga.spec  
> > hit the
> >   repository, which is the same app with a different name. I'm not  
> > sure I
> >   completely agree merging all the spec files into a single one,  
> > however.
> >   Recommendation: Remove.
> >
> >
> >   howl.spec
> >
> >   The direction we seem to be taking is with Apple's Bonjour rather  
> > than this
> >   component. Howl seems to have some difficult licensing  
> > restrictions to allow
> >   it be used in other parts of the stack, to make it something  
> > we're unlikely
> >   to ship in the future.
> >   Reccomendation: Remove
> >
> >
> >   ifrestart.spec
> >
> >   This is a script written by Sun to allow people to 'restart'  
> > their network
> >   connection. The network automagic project is probably where we  
> > want to go.
> >   This script is not currently triggered in the Solaris version of the
> >   gnome-netstatus applet.
> >   Recommendation: Remove
> >
> >
> >   libical.spec,
> >   now.spec,
> >   libghttp.spec
> >
> >   I'm currently involved in an ARC case to remove these components.  
> > libgttp is
> >   currently part of the SUNWgnome-base-libs package, but classified  
> > as a
> >   Volatile interface. The applet is in relatively poor shape in  
> > terms of user
> >   interface, and no active maintenance on any of them.
> >   Recommendation: Remove pending ARC case
> >
> >
> >   libxklavier.spec
> >
> >   This has already undergone an ARC case to remove this  
> > functionality from the
> >   keyboard preference dialog and applet. It serves no purpose  
> > unless we
> >   re-introduce this component at some stage in the future when all  
> > the issues
> >   have been fixed with it.
> >   Recommendation: Remove
> >
> >
> >   magicdev.spec
> >
> >   Magicdev was the old daemon/preference dialog allowing you to set  
> > actions
> >   according to removable media. It was never part of Solaris, and now
> >   gnome-volume-manager and HAL is the natural replacement.
> >   Recommendation: Remove
> >
> >
> >   netapplet.spec
> >
> >   Netapplet was the rewrite of the gnome-netstatus applet, that  
> > turned it into
> >   a notification icon. It's unmaintained, and was never delivered  
> > as part of
> >   Solaris.
> >   Recommendation: Remove
> >
> >
> >   pam-usermode.spec
> >   usermode.spec
> >
> >   Not something that we're going to use, especially with the RBAC/gksu
> >   alternatives.
> >   Recommendation: Remove
> >
> >
> >   perl-XML-Simple.spec
> >
> >   This component is included directly into the SUNW package rather  
> > than
> >   through a child .spec file.
> >   Recommendation: Remove
> >
> >
> >   pilot-link.spec
> >
> >   This component is handled in a different repository for Solaris.
> >   Recommendation: Remove
> >
> >
> >   steel-theme.spec
> >
> >   I'm not actually sure what theme this was - I have a feeling it  
> > might
> >   have been the Sun Ray theme? Are we still intending to ship this
> >   somewhere?
> >   Recommendation: Defer to Erwann
> >
> >
> >   xscreensaver.spec
> >
> >   The X team manage this separately. We were responsible for shipping
> >   xscreensaver on Linux, but not on Solaris. We may take over  
> > maintenance
> >   at some stage in the future, especially so if gnome-screensaver  
> > replaces
> >   it.
> >   Recommendation: Remove for now, revisit later.
> 


Reply via email to