[Bug 168190] Review Request: gpsim - A simulator for Microchip (TM) PIC (TM) microcontrollers

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: gpsim - A simulator for Microchip (TM) PIC (TM) microcontrollers


https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168190





------- Additional Comments From aportal at univ-montp2.fr  2005-10-03 09:28 EST -------
(In reply to comment #11) 
> (In reply to comment #10) 
> > (In reply to comment #9)    
>  
> > No, on unofficial gtk+extra, sonames are libgtkextra-x11-1.1.so*, on 
official   
> > gtk+extra, sonames are libgtkextra-x11-2.0.so*   
> >   
> > What should I have to do? 
> > 
> > Create a package as gtk+extra11 for unofficial version and gtk+extra for  
> > official?  
> That won't help, because other packages potentially to be submitted could 
> require the official gtk+extra-1.x. 
>  
> So you are facing several problems at once: 
> 1. You must replace the current gtk+extra with an official package, either 
2.0 
> or 1.0. 
> 2. The unofficial version must not conflict with any official package. 
>  
> I.e. you have to provide a solution that allows a clean, parallel 
installation 
> of all 3 packages, 'official old', 'official new' and 'inofficial', both 
devel 
> and run-time variant packages. 
>  
> If following the gtk+/gtk2 naming conventions, you could to 
> 1) Put the latest official gtk+extra-1 sources into "gtk+extra" packages and 
> increment the epoch.  
> 2) Ship gtk+extra >2.0 as "gtk2+extra" or "gtk+extra2" 
 
I have to ask the gtk+extra maintener what are the real differences between 
his 1.0.0 and 2.0.0 version. I am not sure that is gtk1 and gtk2, so perhaps 
packaging 1.0.0 won't be needed. 
 
 
> 3) Put the unofficial stuff into an arbitarily named package (say 
gpsim-libs) 
> and hack the package in such a way that this version doesn't conflict with 
any 
> of the official versions (Neither includes nor SONAMEs). 
>  
> Instead of 3) you could merge the "unofficial gtk+extras" with the gpsim 
package 
> and link statically against it. 
>  
> Many other possibilities are possible. As usual things depend on details. 
>  
> The cleanest solution would be to push upstream gpsim to using the current 
> gtk+extra2. If they can provide such a solution in not too distant future, 
> upgrading gtk+extra to 2 and waiting with gpsim probably would be best. 
 
Sure, this is the best solution. I asked for that on the gpsim-devel list. As 
soon I get an answer, I'll feedback. 
 
Can we wait several days before doing something or should I have to do 
something immediatly? 
 

-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.