ltib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ltib] LTIB query


From: Stuart Hughes
Subject: Re: [Ltib] LTIB query
Date: Thu, 27 May 2010 11:11:30 +0100
User-agent: Thunderbird 2.0.0.16 (X11/20080707)

Hi Volatile,

But what is the problem with their content being placed in the LPP?  The
sooner their stuff goes there, the better to avoid name clashes.
There's nothing special about the LPP other than it makes sure you don't
have 2 files of the same name with different content.  Are you worried
about losing/forgetting which files you have put there versus the stuff
on the GPP? if so you don't need to as you can simply run:

$ ./ltib -p <pkg> --dltest

This will tell you which files are not on the GPP for that package (and
which are).

If you really want to make use of per-instance content hiding, you can
place the content in <instance>/rpm/SOURCES.  However it's not something
I can see being particularly useful.

Regards, Stuart

abc xyz wrote:
> Hi Stuart,
> 
> My point is that if  in my machine, if I have multiple users and each
> user has its own set of LTIB. Suppose a user wants to add a new package
> and doesn't want it to be moved into LPP. Every user wants the tarball
> package to be placed in his home directory. Then can a user change his
> spec file according to his search list.
> Because by default the spec file will look for the packages in LPP and
> if it doesnt find it there then it fails. How really can we do the
> modifications in spec file for serarching the package.
> 
>  The spec file or whatever should prompt the user to tell the path to
> search using command line.
> 
> Again this I am using  just because of curiosity as such a thing is
> possible or not. I understand this is not the correct way to do but if
> really this can be done.
> 
> On Thu, May 27, 2010 at 2:33 PM, Stuart Hughes <address@hidden
> <mailto:address@hidden>> wrote:
> 
>     Hi Volatile,
> 
>     Yes you could, but why would you want to?  If you must add a search path
>     %ldirs is probably the right place, but be careful (apply the ideas in
>     the email below).  You will end up crying if you have 2 files of the
>     same name with different content in different content directories.
>     Think about it, you're then at the mercy of the search order, which can
>     be changed by users per LTIB instance.
> 
>     My advice is that unless you can clearly state your reason for what
>     you're trying to do, don't do it at all.  You've not really said why you
>     want to do this and I can't really see a use case.
> 
>     Regards, Stuart
> 
>     abc xyz wrote:
>     > Hi Stuart,
>     >
>     > In such a case can we prevent LTIB from looking in the LPP for a
>     package
>     > and instead redirect it look into some local directory of our choice
>     > without changing the .ltibrc. Can we do something like using an
>     > environment variable in the spec file for the concerned package so
>     that
>     > the user can set this environment variable to point to the source
>     > package and extracts the package into rpm/BUILD.
>     >
>     > On Thu, May 27, 2010 at 2:03 PM, Stuart Hughes <address@hidden
>     <mailto:address@hidden>
>     > <mailto:address@hidden <mailto:address@hidden>>> wrote:
>     >
>     >     Hi Gernot,
>     >
>     >     Just a bit of background information on %ldirs.  Although it
>     can be used
>     >     to provide a way of users storing their own content, it's not
>     intended
>     >     for that.
>     >
>     >     The purpose of %ldirs was mainly to provide a backward
>     compatible way of
>     >      supporting older LTIBs without having to re-duplicate downloaded
>     >     content.  If you look at the setting you see:
>     >
>     >     1. /var/tmp/pkgs
>     >     2. /opt/freescale/pkgs
>     >
>     >     1. Was the really really old place that LTIB stored downloaded
>     content.
>     >      It was chosen as it was open to write by all users.  It soon got
>     >     discarded as I forgot tmpwatch (Fedora) will clean this area
>     up if a
>     >     file hasn't been accessed for x amount of time.
>     >
>     >     2. This is where Freescale BSPs download to, it's still
>     current.  I
>     >     wanted to separate the Savannah/Freescale download areas, but
>     not to
>     >     re-downloaded if content was present in /opt/freescale/pkgs,
>     so that's
>     >     why this is in %ldirs
>     >
>     >     Now back to the original point.  It's best not to extend
>     %ldirs without
>     >     care, for example as a per-user storage (supported by multiple
>     dirs).
>     >     The reason is that you could end up with:
>     >            * duplication of content
>     >            * filename clashes (2 files of same name in different area)
>     >     You could legitimately use %ldirs in a controlled way if you
>     added one
>     >     directory that you were going to use say for your own original
>     (possibly
>     >     sensitive/proprietary) content.
>     >
>     >     Regards, Stuart
>     >
>     >
>     >     Gernot Hillier wrote:
>     >     > Hi!
>     >     >
>     >     > Am 26.05.2010 14:51, schrieb abc xyz:
>     >     > [LPP in another directory]
>     >     >> The point got clear..To maintain uniqueness it is better to
>     put the
>     >     >> tarball in some specific location...
>     >     >
>     >     > Nevertheless, you can do that. See the directive "%ldirs" in
>     your
>     >     .ltibrc.
>     >     >
>     >
>     >     _______________________________________________
>     >     LTIB home page: http://ltib.org
>     >
>     >     Ltib mailing list
>     >     address@hidden <mailto:address@hidden>
>     <mailto:address@hidden <mailto:address@hidden>>
>     >     http://lists.nongnu.org/mailman/listinfo/ltib
>     >
>     >
>     >
>     >
>     > --
>     > Regards,
>     > Volatile
> 
> 
> 
> 
> -- 
> Regards,
> Volatile



reply via email to

[Prev in Thread] Current Thread [Next in Thread]