There's not much we can do here without adding some flag into the build package that it was built in a chroot, and then denying package additions into the repo that don't have this flag

that could be an idea. would devs & tu's go with it though, or would they go "i hate chroots, i don't want to be a dev/tu anymore" ? i'm honestly asking, i haven't thought that much about chroot building.

http://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chroot
It's very easy. People are just a little lazy regarding it. It usually causes no problems though, especially if we use namcap to check deps.

I though you were gonna point to this:  FS#13195 .  FS#13338  is totally unrelated to that.

 FS#13338  applies in the comments. The initial "things are broken" came up due to the fact that people sometimes don't build in clean chroots

then i propose this being implemented :-) perhaps let it "ferment" a bit here if anyone have any objections or ideas?

Keep in mind, this becomes a makepkg feature request then. The pacman devs are much more likely to say "nope!" to it

I had no idea devs built packages outside chroots. I have the feeling most dont. Why does there need to be a flag?
Dont devtools take care of stuff like that?
I dont know what you say to someone when he becomes a developer, but i remember when a new TU get on board, other TUs tell to him "Hey, go read those wiki pages"
Doesnt that happen with developers too?

Yes, dolby, I'm on your side here. Without sounding too harsh: this bug report is an overreaction to a bug in elinks. Most packages are built in chroots, this one was probably a lazy and or quick rebuild. It is a one-off issue that will most likely never happen again, but the bug report makes it sound like it is a plague spreading across development land.

I know there's been many times where I'd had to do a rebuild of something and I just connected to the first arch machine I had available and ran makepkg. This is probably a case like that.

Should i make a new bugreport for makepkg, or "do they know" now?

Dan knows now - let's see what he says

We get like 80 feature requests for stuff like this on the pacman side. There are already perfectly good tools to do chroot builds (e.g. devtools). We decided not to go down this route in the makepkg we work on- if you want one that does, see Frugalware. Enforcing policy like this is NOT the job of makepkg, as far as I can see, and it is up to Arch policy, not makepkg or pacman policy.

I'm also going to say this is a bit of an overreaction. There are several packages that can be safely built not in a chroot, and there are several that cannot. It is up to the individual developer to know their packages, or know when to just take the safe route and build in a chroot.

So everyones agreeing that this isn't a problem? that one doesn't need to build in a chroot? because if so, then what course of action should we take!?

Not every issue is about some sort of global "policy". You're upset about an issue with elinks, correct? Report the bug with elinks, the maintainer will fix it (possibly by rebuilding in a chroot).

I know this happens every so often, but people try to attack these things from the top down, which isn't going to work.

Although I am a big fan of building in chroots, not all packages need built in one. e.g winetricks (http://aur.archlinux.org/packages.php?ID=17313). Building that in a chroot is a waste of my time.

"You're upset about an issue with elinks, correct?" I'm not upset at all anymore. Do i come of as very upset?

This post is all about that I think it is a smart thing to implement policies that will reduce the number of future bugreports. Nothing else.

Sometimes I use words in a... more matter-of-fact way than most people. I didn't mean "upset" as if you were kicking and screaming. I meant "upset" as in... "not settled" or something to that effect.

I think it's smart to implement policies, but this is one of those cases where there's no way we can enforce this and everyone KNOWS it's a good thing. Issues like this are usually caught with core packages anyway.

At some point we ARE going to setup a build server for the devs to use for this stuff, which would use chroots.

I'm a fan of policy to some extent, but enforcing this is difficult and we're just going to hurt ourselves trying to insure it is followed.

if you says so...

 FS#13962  indicates its just a matter of 2-3 devs who dont know the packages they build enough yet.
And its not the first time its happening with python-numpy either.

This is not for makepkg/pacman to enforce... Best thing we can do is get a big stick and whack developers who stuff up dependencies with it. Closing.