On 9/27/05, Mark Rosenstand <[EMAIL PROTECTED]> wrote:
> I've made a feature wishlist for pacman. I'd like to hear your comments!
>
> 1. Option to fake %REASON% when --add'ing packages.
>
> This is handy, for example, if you're installing $makedepend'ed packages
> or a chain of home made packages (e.g., libgalago in order to install
> galago-daemon) and don't want the dependencies to be kept after removing.
This shouldn't be needed. If you're installing homemade packages with
a dependancy chain you should either a) track these things yourself or
b) just run gensync on a local repo and install the top level - it
takes 5 seconds to do this, whereas adding it into pacman will take
much more. The "reason" is part of package management, which pacman
is supposed to do for you, not the other way around. It'd be like
saying "man I wish reiserfs would let me write arbitrary bytes to the
disk so I could fake files" - you don't do that, reiserfs manages
files for you. pacman manages packages for you.
> 2. Deprecation of -Qe in favour of better alternatives:
>
> a) Query option to list all packages that were installed as dependencies
> but
> are no longer depended upon by any installed package.
> Like a global -Rn, but only querying. Removing will probably be to point
> revolvers at too many people's feet.
>
> b) Query option to list all explicitly installed packages, whether depended
> upon by other packages or not. This will reduce the amount of boringness
> associated with cleaning out packages, as you won't have to re-read the
> output of -Qe every time you remove a package because it had unwanted
> dependencies which were also explicitly installed.
For some time I've felt -Qe was a bit wrong. However (dibble will
hate me for this, heh), seeing that the pacman "db" is just a set of
text files, it shouldn't be hard to script both of these things in
about 10-30 bash lines (maybe less in
python/ruby/groovy/erlang/whatever).
Still, I do agree judd needs to rethink the -Qe working a bit.
> 3. Sync option to remove package tarballs for packages not installed on the
> system.
>
> With the current cleaning options (-c), trying out fooapp and deciding that
> it sucks will keep /var/cache/pacman/pkg/fooapp-1.0.pkg.tar.gz until a new
> version of fooapp are in the repos. Since fooapp 1.0 sucks, I probably
> won't
> install it again, and if people tell me that 1.1 kicks ass I'll have to do
> a
> download anyway.
Well, if you're really having diskspace problems with packages, maybe
you should move some partitions around. There are scripts on the
forums (and wiki?) to manage cleaning of the cache, but none for this
specific instance. It shouldn't be hard to modify one of them to
check if a package is still installed, and if not, remove it.
> 4. Declaration of post_install() and friends inside PKGBUILDs.
>
> It seems silly that you're declaring a build() function but need an
> external
> file to declare other basic functions. I do realize that it's easier to
> include the file with install time functions in the tarball, but it
> shouldn't be too hard to extract them from the PKGBUILD and then include.
>
> It's also silly that you have to write the same three lines at the buttom
> of every single install-file.
Well, here's the point you're missing:
the .install file is copied into the package itself. The PKGBUILD is
not. It is converted to metadata and packaged up. If the *_install
functions were to be placed in the PKGBUILD along with the build
function, a simple "cp blah.install whatever" command is replaced by
complicated multiline greps and seds which are going to have to find
pre_install, then match from { to } and redirect that to an install
file to be packaged. Much more work. Much more points of failure.
And where's the gain? .install files really are not *that* common.
Back in the days of my personal repo, and now the community repo, I've
maybe written 5 total. It's just another file, what's the problem
with it?
I could, by the same rationale, say "all the files in /proc should be
one file" or something similar. It sounds like something the busybox
people would say. "Let's take 30 independant things and cram it all
into one app". It sounds good at first, but it is absolutely against
the unix philosophy. ( http://www.faqs.org/docs/artu/ch01s06.html )
- phrakture -
_______________________________________________
arch mailing list
[email protected]
http://www.archlinux.org/mailman/listinfo/arch
