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

List:       crux
Subject:    Re: Errors during Compilation
From:       Mike MacLeod <mikem () ns ! sympatico ! ca>
Date:       2002-06-18 15:10:08
[Download RAW message or body]



Mick Gards wrote:

>hi,
>
>it seems like everyone else has waded into this discussion topic. but there 
>are a few questions that maybe need to be asked. should a regular user be 
>required to view/edit Pkgfiles on a regular basis? i understand that being 
>given access to the Pkgfiles increases the control over the software you'd 
>like to install on your machine, which i personally think is a huge benefit, 
>as people can easily tweak the packages to suit themselves, but should it be 
>necessary to refer to these files when building and installing the packages 
>as provided?
>
>if the answer here is "yes", and the Pkgfiles should be read by everyone who 
>installs a package, then perhaps a more rigidly commented Pkgfile is the way 
>to proceed.
>
>alternatively, if the answer is "no", that is, the Pkgfiles should do their 
>job and remain largely unseen, unless there is a specific need to change a 
>particular package, then perhaps, seeing as a large part of this discussion 
>has been on the dependency checking issue, a simple line could be added to 
>the Pkgfile
>
>depends=( package1, package2 )
>
>and then pkgmk could just print this out, before, or after the build( ), such 
>as:
>
>--- Remember: Package X depends on: package1, package2
>--- You will need to build this package correctly
>
>or similar, to the same effect. this would keep the control that pkgutils 
>provides, ( ie it doesnt descend into dependency-hell like i've seen, for 
>example, apt on debian do ), yet at the same time provide clear instructions 
>for installing a package and its requirements.
>
>on this point, and quoting from the crux.nu -> documentation page
>
>  
>
>>NOTE! There is no package dependency checking. 
>>This means that it is up to you to figure out that if you 
>>for example install the sendmail package you also 
>>need to install the db package.
>>    
>>
> 
>i think the key here, is that knowing the dependencies of a package shouldnt 
>be left up to the user. no-one should be expected to *know* all the 
>dependencies of a particular package. the responsibility of the system then 
>would be to alert the user to the required dependencies, but not actually do 
>the installation for him/her. i understand at the moment a #depends line is 
>used by most package maintainers, but even so, this brings us back to the 
>first question, should users really be referring to these files everytime 
>they expect to build a port/package.
>
I find that the commented dependency system is slightly flawed, because 
the dependencies listed are often out of date, or not in the ports tree 
- both official and unofficial. An example of this is the mplayer port, 
which suggests that contrib/xanim is nice to have, but xanim is no 
longer in contrib, and isn't even in unofficial.

>
>what are the suggestions on this
>
I think the best way might be to include a function in pkgmk that lists 
the dependencies required. By making it a definate part of the Pkgfile, 
maintainers are far more likely to make sure the list is up to date and 
comprehensive. At that point, it can be left alone, or if we, as the 
CRUX user base, decide we like the dependecy checking, we could extend 
it to install these dependencies as well. My suggestion would be to make 
these functions accessable by command line switches though, and to keep 
the current functionality of pkgmk the same; pkgmk -dep or something 
like that.

As CRUX grows, and pkgfiles are written for ever bigger and more complex 
applications, the limitations of the package management system in CRUX 
will start to hinder it's growth. The elegance and simplicity of pkgmk 
and pkgadd are wonderful for the basic system and are key reasons for 
why I love to use CRUX. But the package utilities should grow with the 
needs of the user base as it matures. We need to decide if we want a 
system that builds the core of the system perfectly, with great 
optimization and everything else that makes CRUX wonderful, just so we 
can install a bunch of GNOME and KDE binaries on top, or if we want to 
find elegant solutions to dealing with the complexity of some of the 
applications and platforms out there.

 From my experience with Gnome, even having a feature that lists the 
current dependencies of any given package can still be a pain, 'cause 
you end up starting at the top, and then slowly making your way through 
the packages, checking the dependencies on each one, until you find one 
that is at the bottom of the dependency chain, and then you have to do 
it all over again for the next package and so on... dependency hell.

>
>mike.
>  
>
>  
>
Mike MacLeod

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