brokenman wrote:ncmprhnsbl what is your opinion on the best package manager?
I liked pacaur. It runs as guest and only elevates when required. It uses cower as a backend.
some thought bubbles:
short answer: have tried some , they seem nice
in the context of an arch install
i have packer, yaourt,apacman, and recently pacaur..cower
i like the one that is working and at one time or another they havnt
lately i use yaourt -Sua to get a pretty and detailed aur update report (or just general search)then abort(mostly i search via the webbrowsr)
then i use apacman -S on what i choose to update, one at time mainly because apacman has its own cache (handy for downgrades lest a broken/buggy build occurs)
could do like this with yaourt but am lazy..
in the context of pman.. whatever suits your scripting..
pman already wraps pacman,, so cower could be used on its own(to search and download from AUR) and pman could then run an editor, run makepkg , then build the module....
on the other hand it probly better to use a wrapper that already has functions well written and tested...
working module creaters with AUR support that i have used : makesb(apacman) from alphaOS and makexzm(yaourt) from an earlier Sensei.
it looks like your going for pacaur.. fair enough..
brokenman wrote:Secondly, what do you think of the idea of using manjaro's repositories. I like the idea of being stable. I don't like the idea of triple deps. Porteus relying on manjaro relying on arch.
like the mite on the flea on the cat. a cat eating from an open source bottle.
i tend toward a set date with ALA(ArchLinuxArchive) around the build time/kernel version, with
an eye on the bug tracker to try to avoid nasty surprises at release..all portable archs(tiko) so far have used this(sensei,archpup/alphaOS)
it might depend what sort of release cycle/upgrade mechanism you envisage..
arch states: partial upgrades are not supported. doesnt mean they're not possible
manjaro is 1-2 weeks behind arch adding extra debug filter, but still rolls ..
rolling: does it matter? probly blacklisting the kernel and core pkgs is enough to avoid major breakage even at the end of a longer(>six month?) release cycle
worst that would happen is a package wouldnt work maybe
depending on what sort update activity is going on in the repo
basicly:
arch rolling=unknowns (you might get a package updated several times in one week)
manjaro rolling =less bugs, smoothed out updates? unknowns
ALA=mostly known(wont change), toward end of cycle *could* have breakge with AUR builds,
note: use of 'breakage' > unspecified and hypothetical
a bit of a cop out but, it could be left to the user to decide in the wizard, with a brief explanation of the differences...