[Pkg-electronics-devel] PCB

[pcb-rnd at igor2.repo.hu]

On Fri, 16 Dec 2016, Dima Kogan wrote:

> pcb-rnd at igor2.repo.hu writes:
>
>> On a higher level: in some important aspects pcb-rnd goes in a totally
>> different way than pcb (modularity, portability, scripting, code quality
>> and development methods). That together with dozens of extra features
>> makes me think having pcb in a distro doesn't make pcb-rnd unnecessary,
>> because it's not just another variant of the same software.
>>
>> About Stretch: for pcb-rnd it's more important to get any Debian support
>> than getting into the next stable. Just getting into sid would already be
>> a big step. The wiki says the "Soft" freeze for Stretch is in 3 weeks. I
>> couldn't make any measurable progress with Debian coverage of pcb-rnd
>> since August (4 months) - I don't expect Stretch to be a realistic target.
>
> OK. Thanks for continuing to push on this. I'll look at packaging this
> weekend (tomorrow), and will let you know if anything comes up.

Would be great, thank you!

Some links that might be useful:

upstream web page: http://repo.hu/projects/pcb-rnd

upstream release tarballs (generated page, you can assume the file names 
and urls will always look the same; if the fetch script prefers a 
different page layout or file naming conventions I can write a script to 
generate/symlink them):

http://repo.hu/projects/pcb-rnd/releases/

The releases are the stable versions that are potentially good sources of 
packaging. They are also accessible as svn tags (e.g. 
svn://repo.hu/pcb-rnd/tags/1.1.2 )

Development happens in svn trunk: svn://repo.hu/pcb-rnd/trunk

This also means trunk is usually compilable, but is generally considered 
unstable/experimental.

You can find my latest Debian packaging attempt in 
svn://repo.hu/pcb-rnd/trunk/debian

(I don't plan to keep this directory in trunk/ if pcb-rnd gets official 
packages)

Only 35% of the code is in the core application, the rest is in 
optional plugins. Plugins can be ./configured to be disabled, 
static-linked ("builtin") or dynamic-linked ("plugin", using dlopen). I 
think the best would be to have a set of plugin packages. My packaging 
attempt puts every plugin in a separate package (maximum flexibility). If 
you think that results in too many packages, we may try to group plugins. 
I'd skip GPMI and scripting in the first go.

A more detailed doc written for package maintainers: 
http://repo.hu/projects/pcb-rnd/developer/packaging.txt

Please let me know if you need any upstream support, I'll be generally 
available in the next 2 weeks. I am also interested in making changes or 
merging patches upstream - what needs to be changed for the Debian 
packaging may be useful for other systems as well.


Best regards,

Tibor Palinkas