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

List:       crux
Subject:    Re: Errors during Compilation
From:       Colin Tree <coltree () tpg ! com ! au>
Date:       2002-06-21 2:40:55
[Download RAW message or body]

Hi,

How about something like
# depend=(package1>=1.2.3 package2=4.5 \
#	package3>=3.45 etc)
initially a comment but could easily be a useful format
for implementation. Need to keep track of versions as well.

On Wed, 2002-06-19 at 01:10, Mike MacLeod wrote:
> 
> 
> 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
> 
-- 


Cheers,
Colin Tree


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