[pacman-dev] My thoughts for development
dpmcgee at gmail.com
Wed Dec 20 15:30:29 EST 2006
On 12/20/06, Aaron Griffin <aaronmgriffin at gmail.com> wrote:
> On 12/20/06, Dan McGee <dpmcgee at gmail.com> wrote:
> > a lot
> Wow! That's a lot of text... lemme see here. Before I get into this,
> IRC or jabber makes discussions like this alot "easier" - do you,
> perhaps, use either regularly?
I'm on IRC every once in a while, but not too likely over the next few
weeks here, because I'm at home and not at school. I've never used
jabber but have no real reason not to, but like I said, these would be
easier in the new year. The only other issue is a common time when
people are on. But I definitely have some other things that would be
easier to talk about on a real-time basis, so I'll let you know.
> > 3. I posted a patch for #5223 (source cache) and it has been patched.
> > However, it is now a triple conditional with three different possible
> > locations for package source (current dir, $SRCDEST, and
> > /var/cache/pacman/src). Is the last one necessary since it is highly
> > recommended to not build as root? Should we deprecate this path?
> > Looking even further ahead, should we make fakeroot a requirement for
> > running makepkg?
> Hmmm. Building as root _is_ actually used in one or two oddball cases
> (Judd knows what they are) so explicitly denying them may not work.
> As for the SRCDEST check... why not default SRCDEST to the pacman
> cache dir, and just check one single place for it. It makes sense to
I'll look into this and see if I can't throw another patch together.
> > 7. Integrity checking- currently generating integrity checks will only
> > generate those from the first one in the INTEGRITY_CHECK array. This
> > seems to make sense as long as the array in makepkg.conf is ordered
> > the way we want it to be. When checking, we do get warning messages
> > for other types that may be in the array but are not in the PKGBUILD.
> > I just wanted to confirm this is the behavior you are looking for.
> Erm. It should have generated all of them. If it's not looped, then
> it's an oversight on my part. I actually tested some stuff with md5
> and sha1, then moved back to just md5 for building some packages, so I
> probably missed it.
This happens because of the 'exit 0' line at the end of the 'if [
"$GENINTEG" = "1" ]; then'
loop. It exits after running that entire loop...but not the entire
INTEGRITY_CHECK loop. The way it is currently structured makes this
hard to change besides putting another if after the outer loop
checking the $GENINTEG variable and exiting if it is set so we do not
continue on and do the building.
> > 2. How are you guys doing side-by-side builds with the old pacman? At
> > least for me, the current build system seems horribly complicated with
> > shell scripts, configure, automaking and such. Is there a good reason
> > for this?
> Well, autotools is always a PITA. I'd like to move away from it in
> the future. I haven't pushed this to this list yet, for a handful of
> reasons, but here:
> That's a pacman3 side-by-side install. However, I noticed an issue
> (actually travis did) where if you were to upgrade initscripts, it
> overwrites rc.conf *BUT* it only does it the first time you use this
> package... it did it once, and now it all seems fine. So it's
> something goofy and I need to track that down tonight.
More information about the pacman-dev