# package dependencies



## legreg (Apr 3, 2017)

Hi to all,

I am searching for a very basic information 
Just wondering something about dependencies versions management by pkgng.
I see that, in general, packages have dependencies.
If I try to look at the dependencies of a given package, I see that the versions of the dependencies are very specific.

For example, below are some ruby dependencies:

```
"deps":{
    "libedit":{"origin":"devel/libedit","version":"3.1.20150325_1"},
    "libexecinfo":{"origin":"devel/libexecinfo","version":"1.1_3"},
    "libffi":{"origin":"devel/libffi","version":"3.2.1"},
    "libyaml":{"origin":"textproc/libyaml","version":"0.1.6_2"}
}
```

If I create my own package, is there a way to say: I want a dependency on any version up to 1.0 of the package 'fake_package' instead of specifying the strict version needed ?


Thanks in advance !


----------



## SirDice (Apr 4, 2017)

Porter's Handbook: 5.8.9. Minimal Version of a Dependency

Packages however have set dependencies, so once the port has been built it's going to depend on specific versions of the dependencies. So you can't, for example, depend on mysql-client > 5.5 and expect the package to accept mysql-client 5.6. Once it's been built against 5.5 the package is going to have a hard dependency on mysql-client 5.5.


----------



## legreg (Apr 4, 2017)

Ok, thanks for your answer. This seems to make things complex sometimes.

I would be happy to have your advice and maybe more informations about the following situation:

_my-package_ is based on a git tag, say 1.0, and it has a dependency to _my-dependency_, say at this point 2.0
_my-package_ is built outside of the official repo, but _my-dependency_ is available on the official mirror only
Tomorrow, the _my-dependency_ version becomes 2.1, which makes _my-package_ obsolete while I don't rebuild it

Does it mean that I have to check every day if the version of _my-dependency_ has changed in order to rebuild _my-package_? 
If so:
- When should I check to rebuild _my-package_ exactly in order to avoid the case where someone tries to install my outdated package?
- This also means that _my-package_ remains in 1.0 (while its sources haven't changed), but I still have to provide a new build just to take into account the new version of _my-dependency_, am I right?


In such a case, wouldn't it be a better solution to make _my-package_ and all its dependencies available in a custom repository?
A question remains in this case:
One of the dependencies in my custom repository is _simple-lib-3.0_
So someone which installs my-package from this custom repo will have:
* my-package-1.0
* my-dependency-2.0
* simple-lib-3.0

The same user installs an other package (_other-package_) which depends on _simple-lib_, but a more recent version available on the official mirror, say _simple-lib-4.0_.
Will pkg authorize _other-package_ to be installed while it breaks the _my-package_ dependency? What happens here? 

I know there are a lot of questions in this post, I have tried to be as clear as possible and be sure that I appreciate a lot your answers!


----------



## ShelLuser (Apr 4, 2017)

legreg said:


> In such a case, wouldn't it be a better solution to make _my-package_ and all its dependencies available in a custom repository?


What exactly are you trying to accomplish? I think it might be easier on all of us if we start from there.


----------



## legreg (Apr 5, 2017)

To make things as simple as possible:
Provide a package that I build on my side and which depends on ruby and be sure that the ruby dependency will never be broken!

An I'm actually using "pkg create" to do it, not poudriere and ports...
Anyway, I think it doesn't make a difference here.

I would like to say:
I build a specific version of ruby with a custom name (ruby-custom) for example and all of its dependencies in a custom repository, so I am sure they will remain available.

But I'm not sure that it can work easily

Thanks for help


----------



## SirDice (Apr 5, 2017)

legreg said:


> Provide a package that I build on my side and which depends on ruby and be sure that the ruby dependency will never be broken!


That's not going to work.



> An I'm actually using "pkg create" to do it, not poudriere and ports...


Poudriere builds ports. Ports build packages. Building packages is done with pkg-create(8). So it's all the same.


----------



## legreg (Apr 5, 2017)

SirDice said:


> That's not going to work.



Ok, Thanks, then what is the best approach to do that? Check if dependency has changed and then rebuild my package?


----------



## SirDice (Apr 5, 2017)

Yes, if the port has been created properly it will pick up the changes, but you'll have to rebuild the package if any of the dependencies have been updated.


----------



## legreg (Apr 5, 2017)

Ok thanks, then when does port check for changes?
Because if a new version of my dependency has been built, I need to provide a new version of my package as quickly as possible (and actually I don't use port so I have to automatize the checking)


----------

