Aaron Griffin <[EMAIL PROTECTED]> wrote:
> On 9/27/05, Mark Rosenstand <[EMAIL PROTECTED]> wrote:
> > 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
Exactly what do you mean by "track those things yourself"? I am going to
install libgalago and then galago-daemon, however I wish that should I
some day remove galago-daemon, libgalago will be listed as unneeded by
the option in wish 2a.
> 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.
I should be the one in charge of my system, not pacman.
If I want to install just galago-daemon and thus libgalago, it is a lot
more work to create a repo, add it to pacman.conf, and then install it,
than it is to simply -A the two files.
Please do tell if you think allowing to override it will hurt anybody.
> > 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.
Why rethink it? What's wrong with the purposed method?
> > 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.
I'd rather get rid of the cruft than make more space for it.
> 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.
I did make a script in two minutes and around 300 bytes to do it when Douglas
Soares de Andrade said that he'd like that feature too. However, the
point is that (I wish :-)) it should be implemented in pacman.
> > 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.
No, I haven't missed the point. Hence I wrote "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."
> And where's the gain? .install files really are not *that* common.
Take a wild guess why they aren't common. It's because it sucks to have
to tell the PKGBUILD that it should look for foo.install, then create
foo.install, declare your function and open /var/abs/install.proto to
copy over the three lines that are needed for all install files but
still not automated. I'd be much more likely to include a small
post_install() hint to the user if I could write it while I had the
PKGBUILD opened in my editor anyway, and I think others would too.
> 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?
That it's yet another file.
> 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 )
You are being stupid. It has absolutely nothing to do with the UNIX
philosophy. These are closely related functions and it doesn't make
sense to seperate them as they're never called by anything but makepkg
and pacman.
--
.-. Mark Rosenstand (-.)
oo| cc )
/`'\ (+45) 255 31337 3-n-(
(\_;/) [EMAIL PROTECTED] _(|/`->
_______________________________________________
arch mailing list
[email protected]
http://www.archlinux.org/mailman/listinfo/arch
