reverting "unbundle"

[Chad Miller]

Here in the Debian-ish world, our build process expects to be able to run a command inside the tree to return the tree to the state we found it in, like "make clean".  I have not looked into it a lot yet, but in beta and dev trees, the "unbundle" stage of overwriting included library source with system library source might not have an un-do step for us.

I'm not sure what to do about it yet.

Does anyone else expect a problem with "unbundle"?

- chad

Ubuntu

[Paweł Hajdan, Jr.]

On Mon, May 27, 2013 at 5:05 PM, Chad Miller <chad....@canonical.com> wrote:

Here in the Debian-ish world, our build process expects to be able to run a command inside the tree to return the tree to the state we found it in, like "make clean".

Thanks for feedback and asking about the build/linux/unbundle script.

For future reference, could you explain why is that done (restoring the tree to original state)? Do you have some links to relevant documentation?

I have checked these:

http://www.debian.org/doc/manuals/maint-guide/dreq.en.html#rules

http://wiki.debian.org/debian/patches

http://comments.gmane.org/gmane.linux.debian.devel.general/124240

I think it would be useful for me and other developers to understand the context and rationale behind it.

 

I have not looked into it a lot yet, but in beta and dev trees, the "unbundle" stage of overwriting included library source with system library source might not have an un-do step for us.

Oh, I see. I have a fix in review, https://codereview.chromium.org/16121002/ .

Paweł

[Chad Miller]

I asked around, and (AFAICT) it's not a hard requirement that the "clean" rule actually revert all changes (after I disable some checks of sanity in build options).  It is vitally important that "build" produce the same thing as "build; clean; build", and I assume that's true.

So, maybe it's nothing for you to worry about.

- chad

Ubuntu

[Paweł Hajdan, Jr.]

On Tue, May 28, 2013 at 7:47 AM, Chad Miller <chad....@canonical.com> wrote:

I asked around, and (AFAICT) it's not a hard requirement that the "clean" rule actually revert all changes (after I disable some checks of sanity in build options).

Even though it's not a hard requirement, disabling checks for packaging is not the best thing to do.

It's important for me that people don't need to do that. That's also one of the goals of this mailing list: it is perfectly fine to ask for things like that to be done, even when they are not "absolutely required".

Still, if you could post some more details about which check looks for that and any kind of related documentation, I think it would be useful. Note that my packaging background is Gentoo, which is different from Debian/Ubuntu in details like this.

 

It is vitally important that "build" produce the same thing as "build; clean; build", and I assume that's true.

Yes, it is.

 

So, maybe it's nothing for you to worry about.

https://codereview.chromium.org/16121002/ is now committed. :-D

Paweł

[Chad Miller]

On Tue, May 28, 2013 at 2:59 PM, Paweł Hajdan, Jr. <phajd...@chromium.org> wrote:

On Tue, May 28, 2013 at 7:47 AM, Chad Miller <chad....@canonical.com> wrote:

I asked around, and (AFAICT) it's not a hard requirement that the "clean" rule actually revert all changes (after I disable some checks of sanity in build options).

Even though it's not a hard requirement, disabling checks for packaging is not the best thing to do.

It's important for me that people don't need to do that. That's also one of the goals of this mailing list: it is perfectly fine to ask for things like that to be done, even when they are not "absolutely required".

Still, if you could post some more details about which check looks for that and any kind of related documentation, I think it would be useful. Note that my packaging background is Gentoo, which is different from Debian/Ubuntu in details like this.

Our build tools compare the post-build, post-clean source tree to the original tarball, to verify that the build wasn't based off of anything that is not in the original source.  In some cases when we're iteratively updating packaging, build tools diff against the post-clean of a successful build to discover and save differences as patches.

 

https://codereview.chromium.org/16121002/ is now committed. :-D

That's awesome. Thanks, Paweł.

- chad

Ubuntu