saen acro wrote:
> Dreamcat 4 this fake repo is some compromise
I disagree entirely. Everything is a compromise. I think overall we come away with many major + positives using bintray.com's online hosting service. That taken all into account outweighs the cost of hosting and maintaining our own private debian repo.
> there is normative how to make repo
> but this is out of normative
Ok. From a purely technical standpoint we are overall better off using the distro field for specifying the branch. Because it saves us in other ways. You have yet to prove to anybody there is a real error or technical issue caused by doing so.
Or to put it another way: If it's so terrible / dangerous / problematic to put the 'stable'... in the distro field, then how come that is also the way Google does it for their official Chrome web browser, which is being installed & used by millions of people across the world? Surely if there were some legitimate issue they also would be affected too in same fashion / same ways? Do you think the people who work at google are less knowledgable than you at choosing these things?
> not correct naming and correct path
It is correct. We have listened to your concerns. When they were legitimate ones we have gone back, checked again. Places we had problems, like the metadata signing, then that has been fixed. Thank you.
"Just copy into the *apt.tvheadend.org repo"...
OK that repo is under the control of Adam Sutton. Who is hardly around anymore. He has written those scripts in python. Nobody else really knows how it works. So asking me to do something I am not actually capable of isn't going to produce the desired result. Now think for a minute: how is that better than an MIT licensed open source (fully documented) build guide, and using public bintray rest API + the help of the bintray support team? Who (bintray.com) are also paying for the money to host our project's open source .deb files at no cost whatsoever to tvheadend project. Which ways is best overall, everything considered?
Another point about it:
Copying already signed .debs from bin tray repo into apt.tvheadend.org repo. That is different URL, so we might expect it is probably going to cause some similar metadata signing error (as we saw previously). So perhaps from a technical standpoint it is NOT so convenient. It's precisely the sort of problems that bintray.com are supposed to solve for us with their special knowledge of release management issues. When managing such things in our own apt repo, we don't get bin tray guys to fix such APT repo issue. = maintenance time of us is wasted, which can be better used for making ARM builds for RPI or RPM builds for Centos / Fedora. Which one of those things is best use of resources?