[pacman-dev] command line arguments
ngaba at bibl.u-szeged.hu
Tue Oct 2 06:36:00 EDT 2007
> On 9/29/07, Xavier <shiningxc at gmail.com> wrote:
> > On Sat, Sep 29, 2007 at 01:48:29PM +0200, Nagy Gabor wrote:
> > > A bit off in this thread, but the current command-line handling of pacman
> > > chaotic, for example the bahaviour of -Quil is not defined. We should
> > > restructure a bit, we should categorize options: (my example assumes -S)
> > > -operation: -l, -i, -c, -l, -p, -s, -y ... <- more than one allowed
> (pacman try
> > > to do all requested operations)
> > > -loadtarget/targettype-modifier options, -g, (--provider), -u (!!) ... <-
> > > one allowed
> > > -trans_prepare/new-target-pull options: -d, (--noconflict option), -e ...
> > > more than one allowed
> > > -trans_commit options: -f, --asdeps, -w (do nothing) ... <- more than one
> > > As an example, I explain what should pacman -Quetcl do:
> > > List all explicitly installed outdated not-a-dependency-of-other packages
> > > show their changlogs and filelists ;-)
> > >
> > I think that's a good idea, but a lot of work again :)
> It's always "a lot of work". C'est la vie.
> This is why Dan and I like to harp on people for patches. We're just
> two guys, and we both have full time jobs (ok, I now have a second job
> if you look at the main Arch page) and social lives.
> It's hard to do everything everyone wants.
> That's also why I love when people run their own git branches. I don't
> have to do much extra. I remote update and voila! I have all your work
> to import.
> It's amazing.
> Keep up good the work guys.
OK, I will explain a viewpoint of a patch-sender ;-)
First of all, all of us have few freetime.
To tell the truth I would radically rewrite some parts of pacman. This could be
done at one night (in one-person hobby-projects (unlike pacman) the maintainer
can do this easily ;-). But I cannot do that, because:
-if I send a huge patch, you may not like the result and reject my patch, so I
wasted a lot time [so I won't send huge patches]
-if I send smaller patches depending on each other (to prevent myself from
useless work) I have to wait a lot for your review/apply, and the one-night-work
may become a six-months-work ... [my deps.c and sync.c patches were sent about
2 months ago, and I'm waiting now for your apply/reject, I cannot continue my
work until your decision...]
So patch-senders cannot help more, we just send patches... Please don't ask us
to create a git repo etc., that is needless, if you can _easily_ "decode" our
patches, that should be enough. I appreciate your work on pacman as a developer
(!many thanks, again!), but you should see that sometimes you and Dan slow down
the development (by sitting on patches).
I didn't want to hurt anybody, this was a criticism of a development _model_.
However, I cannot suggest better... but I would give git access to some
talented&enthusiastic guys <- not me;-). Because if I have not enough time for a
project, I will search for other guys, who will enjoy help me <- Aaron: cf. mc
Arch package bugs ;-). Note: English is not my native language, so I cannot
express myself as clearly as I could in Hungarian, so my e-mail may be hurtful
or whatever, sry.
SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu
This mail sent through IMP: http://horde.org/imp/
More information about the pacman-dev