On sábado, 12 de agosto de 2023 20:26:09 -03 Lisandro Damian Nicanor Perez Meyer wrote: > On sábado, 5 de agosto de 2023 12:06:27 -03 Lucas Nussbaum wrote: > > Hi, > > > > Debian Policy section 4.9 says: > > clean (required) > > > > This must undo any effects that the build and binary targets may > > have had, except that it should leave alone any output files > > created in the parent directory by a run of a binary target. > > Now this is something I never understood why it would be needed and it seems > that it might be necessary on other types of flows from the one I use. > > Normally my repos only have the stuff in debian/ committed in them. If a > package fails in a way I need to dig deeper I create a chroot, install the > build dependnecies, untar the source code and work. If I need to clean, git > clean -xdff && untar source code again. > > I could be easily missing something beneficial for my workflow there but, to > be honest, I never really required debian/clean to work. > > And yes, if someone wants to build my packages then they need to understand > how to use git and untar the source code. If they don't, I point them to the > docs (we do have them). > > Also I never seen building a package twice in a row on the archive > happening... so no, at least in my use case, I do not see the value of > debian/ clean. > > But again, I might be missing something here.
Scott Kitterman was kind enough to discuss the issue with me, and he asked me what would I do if I have to work with a Debian source from the archive. That was actually a pretty good question, as I have to do it from time to time: apt-get source foo cd foo-x.y.z git init git add -A debian/ And voilá, now I can work with **any** package from the archive in the way I like. If I need to clean up and start over: git clean -xdff tar -xf ../foo_x.y.x.org.tar.gz --strip=1 Someone might say "hey, but you need to clean and untar each time!". Well, to be honest, I prefer that than relying on a add-on prepared by someone who is probably not upstream, ie, us maintainers. Let's be honest, this might be a flaky target unless you test it each and every time... waste of resources. Someone might say "I do not want git installed". Well, I hope you don't use gbp on your packages either. Now I **do** see value if you are using something like gbp to keep the source code, as you might have modified files there. But that's a peril of your workflow, not mine. I can also understand why that was a fair thing to have when stuff like git was not around, but nowadays... And **again**, I might easily be missing something very important here, but so far I see no reason to do two builds of my packages when I can easily solve it with a couple of commands. Note that I am not saying that we should remove the feature. If the package happens to work with it, the better. If it doesn't and you provide a patch to make it work, awesome! Making it mandatory? No, so far I see no value in wasting my time on that.
signature.asc
Description: This is a digitally signed message part.
