[prev in list] [next in list] [prev in thread] [next in thread] 

List:       crux
Subject:    Re: Do we need a new package utility?
From:       Florian Weber <Florian.Weber () pfaffenhofen ! de>
Date:       2002-06-22 21:34:07
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


</me mounts the soapbox>

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.

</me steps off the soap-box>

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
<shameful grin>

> > [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-----

[prev in list] [next in list] [prev in thread] [next in thread]