Standardize the various repo contents

[wysiwyg]

Good afternoon all!

I have discussed in this forum before about the disorganization between the various repo's of TC, but understand that this is a community project and it is hard to get things sync'ed.  Here is a list of some of the issues presently seen:

- names are not uniform
     Example: foo.tcz in x86 might be foo-ng.tcz in x86_64
- packages are not split the same way
     Example: foo.tcz in x86 might include binaries, documentation, and libraries, whereas there might be foo.tcz, foo-lib.tcz, foo-doc.tcz in x86_64)
- the existence of a package in one repo does not mean it is available in another
     Example: foo.tcz exists for x86, but not for x86_64 or rpi
- the source code used to build the packages may not be the same
     Example: foo.tcz in x86 might be using 1.2.3 version of source code and the x86_64 might use 1.3.4
- the compile flags are not the same
     Example: foo.tcz in x86 might use "--option1=xyz --option2 --option3", whereas "--option2 --option5" may be used to compile for x86_64

Since our fork of TC utilizes its repo packages, I would like to work towards getting them all "aligned" so both projects can benefit - my contribution to the community.  Currently I can build for x86, x86_64, and RPi.  If any one else would like to donate equipment for the other supported CPU's (which look like dCore only at the moment) or perform the compiling for those I can not, that will be a plus.  But even if just the three I can compile for get sync'ed, it will be a very nice start!

I will need working compile scripts for each of the packages among the various repo's and I will apply their 'guts' to a template 'make' script that will set the appropriate compile flags, compile, and split the contents into the proper packge (e.g. bin, lib, doc, etc).  For those interested, please let me know with a reply below or a private message.

Thanks,
Dave

[bmarkus]

- the compile flags are not the same
     Example: foo.tcz in x86 might use "--option1=xyz --option2 --option3", whereas "--option2 --option5" may be used to compile for x86_64

Sure. Different processor archirectures require different options. For example -mtune=i486 has no sense ob x86_64 or -mcpu=armv6 doesn't work on Intel CPU's.

[bmarkus]

Since our fork of TC utilizes its repo packages, I would like to work towards getting them all "aligned" so both projects can benefit - my contribution to the community.  Currently I can build for x86, x86_64, and RPi.  If any one else would like to donate equipment for the other supported CPU's (which look like dCore only at the moment) or perform the compiling for those I can not, that will be a plus.  But even if just the three I can compile for get sync'ed, it will be a very nice start!

If it is an issue of your fork, my advice is to use your own repos. In such case you are free to go on your way without distroying other's work. Or accept TC as it is now. Of course contribution is welcome within current limits and conditions.

[wysiwyg]

- the compile flags are not the same
     Example: foo.tcz in x86 might use "--option1=xyz --option2 --option3", whereas "--option2 --option5" may be used to compile for x86_64

Sure. Different processor archirectures require different options. For example -mtune=i486 has no sense ob x86_64 or -mcpu=armv6 doesn't work on Intel CPU's.

Thanks for the reply bmarkus, but that is not what I'm referring to.

[wysiwyg]

Since our fork of TC utilizes its repo packages, I would like to work towards getting them all "aligned" so both projects can benefit - my contribution to the community.  Currently I can build for x86, x86_64, and RPi.  If any one else would like to donate equipment for the other supported CPU's (which look like dCore only at the moment) or perform the compiling for those I can not, that will be a plus.  But even if just the three I can compile for get sync'ed, it will be a very nice start!

If it is an issue of your fork, my advice is to use your own repos. In such case you are free to go on your way without distroying other's work. Or accept TC as it is now. Of course contribution is welcome within current limits and conditions.

Wow!  I can't believe you would try to drive away someone that is trying to help both projects.  It is interesting because you see posts in the forum about this package doesn't exist in this repo and here I am trying to get that package in that repo and you're telling me to go elsewhere.  Astounding!  Thanks for your take on it bmarkus.  If anyone else would like to help, I will stick to the original post.

[gerald_clark]

Wow! I can't believe you would try to dictate how somebody else manages their own project.

[andyj]

If it is an issue of your fork, my advice is to use your own repos. In such case you are free to go on your way without distroying other's work. Or accept TC as it is now. Of course contribution is welcome within current limits and conditions.

I like many others use TC because it has a number of advantages over other distros. It also has one glaring disadvantage, which is the lack of a consistant build and naming system. Many people have come to this forum and have pointed out this fact and offered to help, but to be fair it would be a huge undertaking. I maintain about 100 extentions for various services and libraries, and I have my own build system that's taken a while to get working consistently across platforms. There are obstacles to be sure. But I don't think telling everyone they can take it or leave it and that the single biggest weakness is something that shouldn't be discussed is a good strategy. And I certainly don't see how offering to help is an attempt to destroy another's work.

[wysiwyg]

Wow! I can't believe you would try to dictate how somebody else manages their own project.

Can you please point to me where in the OP is says that "TC will need to do things this way"?  I certainly can't.  I have re-read it several times and it looks like an offer for helping the community to me without any demands whatsoever.  In fact, there is acknowledgement in the post itself about understanding why it is the way it is.

There are problems with the TC repo's plain and simple.  There are many posts about this in the forum as andyj has pointed out.  Pretending that there isn't is not going to fix the problem or make things any better.  However, many hands make for light work.  If you want to help, then help.  But please don't make up accusations about what I said when clearly everyone can see you are incorrect.

[Misalf]

I'm not sure. Maybe it's best to just provide stuff and see how it goes. There is always room for improvement. Arguing about things that didn't even have happened yet doesn't feed the fish.

[wysiwyg]

Thanks for the reply Misalf, would you be interested in helping? 

[Misalf]

I have some custom extensions, some may even be "fixed" where I saw fit. I'll take a look at those the next days and will evaluate if submitting makes sense. The reason I didn't just submit them is because I didn't want to break things. :p

[Juanito]

please don't submit any extension with the same name as one maintained by somebody else without first asking them for their approval

[wysiwyg]

please don't submit any extension with the same name as one maintained by somebody else without first asking them for their approval

No worries Juanito.  In fact I am working with others that already work with you on getting packages in the TC repo.  But just as a side note, not I nor anyone else, is interested in taking ownership of the packages, we are simply trying to work with them to create uniform make scripts and then we can compile them for all supported platforms since we have the hardware.  That's why I am asking for help from those in the community that have already created a make script, but they may only be able to get it working for x86 for example.  We would like to work with that person to patch their make script so we can compile for each of the other repos - making them standardized.

As stated several people have stepped forward to help in this process.  Please private message me if you are interested because "many hands make for light work".

[andyj]

I have a (philosophical) question about dependency files for -dev extensions. Should the -dev.tcz.dep file contain only those extensions needed to use the extension (presumably to build other extensions), or should it contain all the extensions need to build the extension itself? Due to optional modules and the like, these are not necessarily the same.

[Juanito]

I believe that the *dev.tcz.dep file should contain all of the files required to build the corresponding *tcz.dep extension as built:

In some cases (for example gst-plugins-*, grillo-plugins*, etc) this would be more than the corresponding *tcz.dep file, which contains only the most used optional deps to avoid loading a bunch of unused extensions.

Note that all required runtime deps (not required to build the extension) should be in the *tcz.dep file referenced by the *dev.tcz.dep file.