Hi Neal
mangling packaging data into source code. I really wish they'd change how the source packaging model worked to firmly split it.
Would you be prepared to expand on this, please? I don't understand it. Perhaps it's because my historical experience is the inverse of yours (familiar with Deb, not too great with RPM).
From my POV Debian has a firmer split than RPM-style (orig.tar.gz; ./debian sub-dir; etc) so I must be missing something.
- replies
- 0
- announces
- 0
- likes
- 1
@neal @andrew_shadura I think I understand better where you are coming from. Interestingly, pre-git it was more common to work with a fully split repo as you describe: with e.g. svn-buildpackage teams (inc. games team) typically kept only ./debian in the VCS.
Most packages moved to "upstream source present" in the debian branch with the move to git, partly because it was much more convenient to work with.
Most packages moved to "upstream source present" in the debian branch with the move to git, partly because it was much more convenient to work with.
@neal @andrew_shadura that said, the most common source layout in debian packaging *with* git is for the source outside ./debian to be unmodified, and a stack of patches in debian/patches. IMHO this is a pain in the arse to work with: it lacks the convenience of "source as it is built", and the separation of "only ./debian is tracked". The worst of both worlds. It looks like Dgit encourages a move away from this.
@neal @andrew_shadura Thanks for expanding. We agree that it's important to clearly distinguish between upstream and the distro changes; and that carrying too many changes at the distro level has serious drawbacks. Where we differ seems to be whether Dgit will make those matters worse or not. Frankly I don't know, but it's a concern worth taking seriously.