From crux Sat Jun 22 21:34:07 2002 From: Florian Weber Date: Sat, 22 Jun 2002 21:34:07 +0000 To: crux Subject: Re: Do we need a new package utility? X-MARC-Message: https://marc.info/?l=crux&m=102478204822710 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The mails during the last days got me thinking: - From the beginning, CRUX did not have dependencies (for good reason). Now we are purposefully trying to introduce them. Should that be done? To what extent should it be done? I don't know, to be honest. I'm quite torn myself. (That's obvious from my postings, isn't it?) At least we all seem to pretty much agree that dependencies shouldn't become part of pkgmk :-) If we just wanted an easy way to install, say, KDE, as a whole, why don't we just create .../kde-package/Pkgfile that says "cd /usr/ports/kde/kdelibs; pkgmk -i" and so on? The only problem is that there are no source files for those "packages", but that's something that could even be solved within pkgmk. I'd say: let's try dependencies. Seperately from the 'standard CRUX'. If (or when) it works, put the tools into the distribution. And then put a *big* *red* *disclaimer* into the package guidelines that dependencies are not there for everyday use ("ImageMagick depends on jpeg" Doh!) but *only* for the very special occasion that a big software suite comes in separate packages. And of course the pkgmk-way of doing things must not be touched in the least by the new stuff. Dependencies *can* make life easier even for experts. And they can also make it pure hell. For CRUX they should be used extremely sparsely. And now to something completely different: On Friday 21 June 2002 11:26, Johannes Winkelmann wrote: [ Sorry I sent this mail in private at first, Johannes. It was actually meant to go to the list. The part below is unchanged, only my thoughts above are now stated more clearly. ] > > [...] Instead of > > using only the port name, use the port's name relative to it's root > > /usr/ports/base/bash --> base/bash > > Rules: > > - - If a qualified port name (e.g. base/bash) is given, only ports > > with exactly this name match. > Why would you like this qualification? I think that if a user > has his/her own port of bash, why should he/she not want to use that? > And why should the packager (writing the Pkgfile) take this decision, > not the user while editing the port roots in /etc/prt-get.conf? But what if I have *multiple* "own" ports of bash? (bad example, I admit ... let's use the KDE suite) > I think it should be the user's responsibility to use the correct order > of port directories to choose whatever port he/she wants to use. Yes, definitely. If I do not explicitly ask for a certain port, ordering should be done implicitly via prt_dirs[] > Another problem is that if you specify dependecies explicitely, you'll > get an error if something is moved to contrib, or out of contrib. Then I was not thinking of the standard base/contrib/opt sections. For those packages, using explicit names does, of course, not make sense. The normal case really *should* be to specify ports with non-qualified names. Again, see below. > we would have to specify rules when packages are allowed to hardcode > pools (like base/opt/contrib/unofficial). A possible rule would be that That would be ... overkill (at least) > I fail to see a good example (due to a lack of imagination :-)), as I > only have duplicate ports where I always want to use my modified one and > therefore just place its directory before the other port roots. Do you > have a use case? Yes I do :-) But it is quite convoluted and will probably be used by very few people ever. Basically I would like to keep multiple user-defined trees that should stay separate from each other - while retaining the possiblity to do a simple recursive build on all of them. The reason: I'm acting as a "distributor" for quite a lot of friends, creating several customized "binary CRUX distributions" (sort of ...). Compilation is done on my machine (hence my needs), they only pull the packages and install them. (this last part is still a dream - but with CRUX I could probably pull it off) BUT: While thinking about my problem, I came up with another solution: - - - only non-qualified port names When checking dependencies for port foo: - - - always look in foo's prt_dir (and subdirectories) first - - - then search according to prt_dirs[] That would get rid of the (admittedly) overengineered approach of using "qualified" prt names. > > - - "Pkgfile.local" becomes trivial > It's trivial without the specification, just use pkgclose.sh (shameless > plug) in /usr/ports/local and specify /usr/ports/local before all the > other ports directories :-) To be honest, I did not check out your tools yet > > [upper *and* lower boundaries for dependendy versions] > but I fear this will lead to a new dimension of dependecy hell: packageA On the other hand, think about KDE: even with current CVS, you cannot use gcc-3.0 or later. KDE won't compile (at least their website said so, last time I looked) Dependencies *are* hell, for humans and software tools alike. The trick with them really is to specify the minimum set. You probably should put in an override switch --ignore-missing-dependencies that warns about those, but compiles anyway. > way (no dependencies stored), I don't intend to implement such things I absolutely agree with you. Dependency hell, or anything even vaguely resembling it, must not happen. After all, that's one of the main reasons for using CRUX. > right now. All I want is a tool to _install_ a suite of applications - Errmmm ... yes. However, once you have that in place, calling the same routines with "pkgmk - - -u" instead of "pkgmk -i" becomes quite easy. (I have not yet looked at your code, but I assume it's quite modular). Nevertheless, this is something that can be added later, if at all, with minimal disturbance of existing code. Off topic: when you support dependencies during package *removal*, that is when it starts to get really hairy > Anyway, from the developer's point of view your idea is an extention to > mine, so I'll proceed as planned (ok, there is no actual plan :-)) and > we can then incorporate it if you still need it, ok ? Sure. :-) If you don't want to do it, be it for not thinking it a good idea, lack of motivation or simply lack of time, I'll do it myself when I really *do* need it. (or not at all) Florian PS: I can't get rid of the nasty impression that what I'm trying to do calls for one of the monsters: rpm, dpkg and friends. Am I right? Please say no! - -- The CRUX with this computer is ...... already installed ;-) PGP key ID: 3C4E74DC -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9FO1Qm8fasDxOdNwRAg7tAKDAcOf3dSLUuwl9HiQQeTGsRpoipQCgoTuA WB1yoChDHRWbfUvx8J4kkVo= =kRAz -----END PGP SIGNATURE-----