name/version was(Re: linux package)

Neven Has haski at sezampro.yu
Thu Feb 15 04:35:10 PST 2001

On Thu, Feb 15, 2001 at 01:21:34AM +0000, Bryan Dumm wrote:

> > > This is not hard, it's impossible. :)
> > > We can use package names, open it and read the top level directory or
> > > even grep some files in it, but we can never be 100% sure. How I wish we
> > > could ...
> >
> > One could depend on the filename. Sensible tarball names have the version
> > in it. But then again one can't trust that scheme either. Take the bind
> > package. You download it as bind-src.tar.gz.

My point exactly. I think it important to be 100% sure in this case.

> And considering where we are all @ with ALFS @ the moment, I 
> think we will have to live with it. The reason why this is happening
> is because we do not have frontends @ the moment. This problem 
> is really not a backend job, and with everyone trying to stuff it into
> the backend, we are going down the road with uncertainity. 

Yes, I agree it's not a backend job.

But until we have a frontend, if somebody is interested, I could code another 
helper script that would make changing those packages names/versions/whatever 
easier, without going through the profile and searching for parts that needs 
I'm not talking about some great user-friendly application, but a simple and
dirty code, that would just list all the tags one after another and allow
changing parts of them by entering numbers, for example:

1-1,2  <package name="bin86" version="0.15.3">

2-1,2  <unpack archive="&packages_dir;/bin86-0.15.1.tar.bz2">&builddir;</unpack>

3-1    <make dir="&builddir;/bin86" />

4-1,2  <make_install dir="&builddir;/bin86" param1="PREFIX=/usr" />

5-1    <remove>&builddir;/bin86</remove>

Now if you enter "4-1" you would change the first "changeable" part of 
the fourth line.

Dirty, but could make things a bit easier.

> Now how the frontend deals with this before sending the profile, 
> I am not sure yet. We might need to add some elements to our 
> framework for like <discovery> or something? I know some <packages>
> would have urls in them for discovery, so I dunno where to go with it.

Maybe the frontend should go through the whole profile once, and just
check for missing stuff. Stuff like package names or maybe even some
non-existing directories for example. But mainly package names/versions.
Then, if something is missing, he would just prompt the user for corrections,
and then feed the backend.


More information about the alfs-discuss mailing list