[pacman-dev] Ideas welcome?

Allan McRae allan at archlinux.org
Thu Jun 24 22:09:33 EDT 2010

On 25/06/10 10:49, Loui Chang wrote:
> On Fri 25 Jun 2010 09:18 +1000, Allan McRae wrote:
>> On 25/06/10 02:58, Loui Chang wrote:
>>> On Thu 24 Jun 2010 18:28 +0200, Cedric Staniewski wrote:
>>>> On 17.06.2010 17:09, Loui Chang wrote:
>>>>> On Fri 18 Jun 2010 00:30 +1000, Allan McRae wrote:
>>>>>> I think I have found the issue here.   We obviously have a NOPASSWD
>>>>>> entry in our sudoers file so "sudo -l" does not require a password.
>>>>>> So the bug is confirmed.  However the fix is not fully functional as
>>>>>> if I have sudo installed but can not use it for pacman, then I can
>>>>>> no longer fall back to using "su -c".  I'd choose excess password
>>>>>> typing over functionality loss.
>>>>> Why not just take sudo and asroot out of the equation and treat makepkg
>>>>> as a real non-handholding executable?
>>>> I'd like to add that "sudo -l" was never meant as hand-holding. The
>>>> intention was to support pacman-wrappers/replacements that aren't
>>>> supposed to be run as root because they have their own logic to call
>>>> pacman as root. The most prominent example would be yaourt, I guess.
>>>> But since this is broken due to the 'su -c' patch, I'm fine with
>>>> removing it again.
>>> Yeah it just kind of bothers me that makepkg is doing all these
>>> auxiliary functions like package installation, uninstallation, and
>>> permissions managment. It has lost its focus.
>> You know that dependency installation etc was a very, very early
>> feature so how can makepkg have "lost its focus"?
> You're right. I should say that it lacks focus.
>>> I think those things are better placed in outside scripts (like yaourt).
>>> It almost seems like the only thing stopping it from becoming another
>>> yaourt is that we've dubbed the AUR as untrusted.
>> So you use makepkg to update your system?
>> Seriously, if you are recommending that automatic dependency is
>> removed from makepkg, you need to go away, do some more packaging
>> and then reevaluate your opinion.
> Yes I am recommending that it be -moved- from makepkg, but how does that
> mean I need to go away? I never said that it is unneccessary. I just
> believe the auxiliary functions should be moved into other scripts.

I said "go away, do some packaging"  not just go away...   Automatic 
dependency checking, installation (and removal) is an essential part of 
makepkg.  I doubt any heavy makepkg user would disagree with me there. 
So what would moving it to another script achieve in practice?  It would 
be a script likely only used by makepkg, essential to any real world use 
of makepkg and maintained alongside makepkg.  And to be clear, you said 
"those things are better placed in outside scripts (like yaourt)" which 
implies you did not see them as necessary in the makepkg code base.

> I hardly need to do any packaging to see the flaws in the AUR, aurtools
> (defunct), and devtools. What makes makepkg the exception?

makepkg does packaging...  none of the other tools you mention do.

> I don't understand how my opinion on the design of the tools would be so
> dramatically changed whether I've made 10 packages, or 100.

Making 10 packages means you refer to things like "package installation, 
uninstallation" as "auxiliary functions". Making 1000s of packages means 
you see them as essential and not feature bloat as you original email 
labeled them.  Much like I only have 1 AUR package installed, so I see 
no need for AUR helpers while heary AUR users strong disagree.

> At least you could say "patches welcome". I guess that wouldn't be of
> much use though, because you've already completely dismissed my
> comments. Sorry. I didn't mean to offend your own opinions.

I say patches welcome when I like the idea.   You original email said "I 
think those things are better placed in outside scripts (like yaourt)". 
  That tells me you do not even want this in the makepkg code base.  I 
strongly disagreed so what would be the point of welcoming patches for it...


More information about the pacman-dev mailing list