On Fri, May 22, 2020 at 09:14:14PM -0400, Przemek Klosowski via devel wrote:
> The scheme you are proposing is kind-of used for Java and Go, and is
> sometimes known as 'vendoring' because it allows publishing software in
> complete dependency bundles independent of anything else. It works as long
On Fri, May 22, 2020 at 07:48:53PM -0500, Parker Gibson wrote:
> The issue I see is that no package management system I know of handles
> multiple so versions, they explicitly state packages conflict with
> each-other even if in principle the so versioning means they would not.
Gentoo portage when
As this topic comes up, I think the issue is more related to cases where
upstream is not willing to support FHS installation. PETSc [1] is one
case, openfoam [2] is another example which is currently under review
[3]. The issue is that derived projects get used to this case of
installation, which t
Paul Dufresne via devel writes:
> Now I do believe the reason you need to give a version to shared
> libraries is because of the FHS. Because FHS suggest to regroup
> libraries inside a specific directory and/or directories. But if you
> have a common directory that contains every packages
On Fri, 22 May 2020 at 21:07, Paul Dufresne via devel <
devel@lists.fedoraproject.org> wrote:
[..]
> The main disadvantage of it, is making hard to have multiple active
> versions of a package, because the likelihood of the multiple versions,
> to have the same preferred place in the hierarchy for
On Sat, May 23, 2020 at 01:01:04PM +0200, Vít Ondruch wrote:
> It would be possible to install individual RPMs into paths such as:
>
> ~~~
>
> /pkgs/programA_version1
> /pkgs/libX_version1 contains
>
> ~~~
>
> but I wonder how would you imagine the glue above this structure to make
> the progra
It would be possible to install individual RPMs into paths such as:
~~~
/pkgs/programA_version1
/pkgs/libX_version1 contains
~~~
but I wonder how would you imagine the glue above this structure to make
the programA_version1 to use the libX_version1?
Vít
Dne 22. 05. 20 v 21:50 Paul Dufresne
On 5/22/20 8:48 PM, Parker Gibson wrote:
The issue I see is that no package management system I know of handles multiple
so versions, they explicitly state packages conflict with each-other even if in
principle the so versioning means they would not.
The example I gave is from my own system.
The issue I see is that no package management system I know of handles multiple
so versions, they explicitly state packages conflict with each-other even if in
principle the so versioning means they would not. Some repositories can handle
multiple major so versions and I do think this may provid
On Fri, May 22, 2020 at 4:37 PM Stephen John Smoogen wrote:
>
>
>
> On Fri, 22 May 2020 at 15:59, Paul Dufresne via devel
> wrote:
>>
>> The File Hierarchy Standard (FHS), is a standard that define where the
>> files of a package should be placed in the root directory of the
>> systems. It proba
On 5/22/20 6:23 PM, Paul Dufresne via devel wrote:
So let's take an example:
At first you have:
/pkgs/programA_version1 that have a LD_LIBRARY_PATH that contains
/pkgs/libX_version1
/pkgs/libX_version1 contains libX, version 1.
Now you "upgrade" libX vesion 2... because each packages is in it
On 5/22/20 4:22 PM, Parker Gibson wrote:
I don’t think this is specifically about FHS as it is about shared library
management. The underlying hierarchy defined in FHS doesn’t make the dictations
about version management that you seem to indicate, nor are the major problems
with maintaining mu
On Fri, 22 May 2020 at 15:59, Paul Dufresne via devel <
devel@lists.fedoraproject.org> wrote:
> The File Hierarchy Standard (FHS), is a standard that define where the
> files of a package should be placed in the root directory of the
> systems. It probably did not change much since the beginning o
I don’t think this is specifically about FHS as it is about shared library
management. The underlying hierarchy defined in FHS doesn’t make the dictations
about version management that you seem to indicate, nor are the major problems
with maintaining multiple api compatible versions of shared li
The File Hierarchy Standard (FHS), is a standard that define where the
files of a package should be placed in the root directory of the
systems. It probably did not change much since the beginning of Unix,
and it make files be placed where users, developers and administrators
expect them to be.
15 matches
Mail list logo
