RE: ipkg 0.116

From: A.Pearce <A.Pearce_at_salford.ac.uk>
Date: Wed, 3 Mar 2004 13:41:34 -0000

Just For Completeness in the familiar ipkg.comf
There is the line

dest ext /mnt/hda

of cource that's ok when I install my C/F Card
but when its not installed the list file is on the internal Filesystem

I read about a "union mount" or transparent mounts in other Unix's BSD
??
 
http://www.ussg.iu.edu/hypermail/linux/kernel/9911.2/0350.html

would this be an alternative ???

It's a pity you cannot do (as a path not a variable)

$QTDIR = /Opt/QtPalmtop;/mnt/hda/QtPalmtop

-----Original Message-----
From: wim delvaux [mailto:wim.delvaux_at_adaptiveplanet.com]
Sent: 03 March 2004 12:54
To: Brad Campbell; familiar_at_handhelds.org
Subject: Re: [Familiar] ipkg 0.116

>
> Except this package contains no post* pre* files at all. It simply
gets
> installed on the flash wherever it's told to be.
>
> I have a little app that runs that scans all inserted media for
> usr/lib/ipkg/info/*.list files and creates symlinks from the root dir
"/"
> to the target files to make the OS think they are installed on the
flash.
> Simple.

        Ah, I see ...

>
> My point is I can see no good reason for storing
> /mnt/card2/opt/QtPalmtop/bin/knights instead of
> /opt/QtPalmtop/bin/knights

        Well that I do not know. I only know it DOES put the INSTALL
path
        in the list file. That already before my patch the case

>
> as ipkg figures out the root prefix from the location of the list
file.
> Doing it this "new" way also creates problems if I rename mountpoints
or
> insert my CF cards in the sleeve in the wrong order. Doing it the
"Old" way
> had none of these problems.

        renaming paths or dirs ALWAYS creates problems and always needs
workarounds
(like creating a link to the old mountpoint) Again it would be better
to use
logical mountpoint names (much like what is needed for devfs)

>
> It does not come down to what the package itself does, simply what the
> link/unlink program does with the .list files.
>
> It's not a hassle, I can modify the program to cope with absolute
paths, I
> just can't see the reason for removing the flexibility of different
> mountpoints or complete filesystem relocation for no apparent gain and
more
> complexity.

        If you move mount points I would always suggest creating a link
pointing from
the old dir to the new dir (or better NOT depend on physical mount
points
altogether)

        What can I say ... ipkg does it this way. I just noticed that
it stored
these paths in an absolute way. I do not know the reason for this
decision
only a solution to some ipkg bugs.

        HTH
        W

>
> Regards,
> Brad
> _______________________________________________
> The Familiar Linux Distribution
> Familiar mailing list
> Familiar_at_handhelds.org
> https://handhelds.org/mailman/listinfo/familiar
> irc://irc.freenode.net #familiar

_______________________________________________
The Familiar Linux Distribution
Familiar mailing list
Familiar_at_handhelds.org
https://handhelds.org/mailman/listinfo/familiar
irc://irc.freenode.net #familiar
Received on Wed Mar 03 2004 - 13:41:39 EST

This archive was generated by hypermail 2.2.0 : Mon Jul 25 2005 - 17:14:17 EDT