Embedded Linux Package Management

Embedded Linux Package Management

[Prasant J]

Hi,

I'm looking for package management for my embedded linux systems
(yocto on armv7 iMX6Q)


I'm looking for the following features:

(a) Install & remove a package
(b) Install packages and its dependencies
(c) Install a package with conflicts, such that the conflicting
package is force removed
(d) A local location with packages should serve as a package source
(e) Remote server package (http file server based)
(f) List of my packages installed
(g) List of my packages not installed but available on the http file server
(h) List of my packages that have updates (new version)
(i) To be able to manage packages for multiple architectures (eg. rpm
can produce packages for multiple architectures using one spec file)


The above features will be invoked by the application GUI.
Any suggestions: which package management solution would answer all
the above use cases?


I have tried smart + rpm, but from my preliminary research suggests
that smart is no longer developed (Am I correct?). Also I failed to
setup remote repository [case (e)] and also case (h) failed.


I am currently trying out yum + rpm, but it fails to answer case (f).
It can lists all my packages but does not tell me if it is installed
or available on the repo.
I could make it work by additional steps (work around), but it will be
good if the tool itself supports these features.
It also fails case (c), does not force remove conflicting package.


I also looked at opkg, but the last stable release seems to be v0.2.4
(v0.3.0-rc2 is current). Is it mature enough to be used? Does ipk
packages support all features as rpm packages would support
(dependencies, conflicts, groups) ?


Sorry for asking a lot of questions. It would be very helpful if
someone who has worked with package management on linux systems can
give some inputs.


Thanks in advance!

Regards, Pj

Re: Embedded Linux Package Management

[Alex J Lennon]

[-- Attachment #1: Type: text/plain, Size: 1312 bytes --]



On 20/03/2015 09:34, Prasant J wrote:
> Hi,
>
> I'm looking for package management for my embedded linux systems
> (yocto on armv7 iMX6Q)
>
>
> I'm looking for the following features:
>
> (a) Install & remove a package
> (b) Install packages and its dependencies
> (c) Install a package with conflicts, such that the conflicting
> package is force removed
> (d) A local location with packages should serve as a package source
> (e) Remote server package (http file server based)
> (f) List of my packages installed
> (g) List of my packages not installed but available on the http file server
> (h) List of my packages that have updates (new version)
> (i) To be able to manage packages for multiple architectures (eg. rpm
> can produce packages for multiple architectures using one spec file)
>
>
> The above features will be invoked by the application GUI.
> Any suggestions: which package management solution would answer all
> the above use cases?
>
>

(e) I use smart + RPM. I have a remote package server setup via this in
local.conf

FEED_DEPLOYDIR_BASE_URI = "http://packages.foo.bar"

Then I'm rsyncing the files up to the server after a bitbake package-index.

Then smart update / search / install

That seems to work well in my testing.

Regards,

Alex


[-- Attachment #2: Type: text/html, Size: 2246 bytes --]

Re: Embedded Linux Package Management

[Prasant J]

On Fri, Mar 20, 2015 at 2:21 PM, Alex J Lennon
<ajlennon@dynamicdevices.co.uk> wrote:
>
>
> On 20/03/2015 09:34, Prasant J wrote:
>
> Hi,
>
> I'm looking for package management for my embedded linux systems
> (yocto on armv7 iMX6Q)
>
>
> I'm looking for the following features:
>
> (a) Install & remove a package
> (b) Install packages and its dependencies
> (c) Install a package with conflicts, such that the conflicting
> package is force removed
> (d) A local location with packages should serve as a package source
> (e) Remote server package (http file server based)
> (f) List of my packages installed
> (g) List of my packages not installed but available on the http file server
> (h) List of my packages that have updates (new version)
> (i) To be able to manage packages for multiple architectures (eg. rpm
> can produce packages for multiple architectures using one spec file)
>
>
> The above features will be invoked by the application GUI.
> Any suggestions: which package management solution would answer all
> the above use cases?
>
>
>
> (e) I use smart + RPM. I have a remote package server setup via this in
> local.conf
>
> FEED_DEPLOYDIR_BASE_URI = "http://packages.foo.bar"
>
> Then I'm rsyncing the files up to the server after a bitbake package-index.
>
> Then smart update / search / install
>
> That seems to work well in my testing.
>


Hi Alex,

Thanks for inputs!

Is smart development stopped?

When I look at their mailing list it, the last posts were in Nov 2014.
It looks like no more development for smart package manager. I would
then tend to say that it will not be a right way for me.


Regards, Pj

Re: Embedded Linux Package Management

[Alex J Lennon]

On 20/03/2015 11:15, Prasant J wrote:
> On Fri, Mar 20, 2015 at 2:21 PM, Alex J Lennon
> <ajlennon@dynamicdevices.co.uk> wrote:
>>
>> On 20/03/2015 09:34, Prasant J wrote:
>>
>> Hi,
>>
>> I'm looking for package management for my embedded linux systems
>> (yocto on armv7 iMX6Q)
>>
>>
>> I'm looking for the following features:
>>
>> (a) Install & remove a package
>> (b) Install packages and its dependencies
>> (c) Install a package with conflicts, such that the conflicting
>> package is force removed
>> (d) A local location with packages should serve as a package source
>> (e) Remote server package (http file server based)
>> (f) List of my packages installed
>> (g) List of my packages not installed but available on the http file server
>> (h) List of my packages that have updates (new version)
>> (i) To be able to manage packages for multiple architectures (eg. rpm
>> can produce packages for multiple architectures using one spec file)
>>
>>
>> The above features will be invoked by the application GUI.
>> Any suggestions: which package management solution would answer all
>> the above use cases?
>>
>>
>>
>> (e) I use smart + RPM. I have a remote package server setup via this in
>> local.conf
>>
>> FEED_DEPLOYDIR_BASE_URI = "http://packages.foo.bar"
>>
>> Then I'm rsyncing the files up to the server after a bitbake package-index.
>>
>> Then smart update / search / install
>>
>> That seems to work well in my testing.
>>
>
> Hi Alex,
>
> Thanks for inputs!
>
> Is smart development stopped?
>
> When I look at their mailing list it, the last posts were in Nov 2014.
> It looks like no more development for smart package manager. I would
> then tend to say that it will not be a right way for me.
>

I don't know. To me the question would be does it do want I need it to
do as well as I need it to do it,
rather than asking whether there is a lot of activity. One might take
the view that if it is doing its job,
a lack of activity is a sign that it's a mature piece of software that
needs little further development.

You'll have to make that decision yourself.

My understanding is that smart is the recommended way to do things (at
least it was what was
recommended to me) - https://wiki.yoctoproject.org/wiki/Smart

Regards, Alex
 

Re: Embedded Linux Package Management

[Paul Eggleton]

On Friday 20 March 2015 11:26:43 Alex J Lennon wrote:
> On 20/03/2015 11:15, Prasant J wrote:
> > On Fri, Mar 20, 2015 at 2:21 PM, Alex J Lennon
> > 
> > <ajlennon@dynamicdevices.co.uk> wrote:
> >> On 20/03/2015 09:34, Prasant J wrote:
> >> 
> >> Hi,
> >> 
> >> I'm looking for package management for my embedded linux systems
> >> (yocto on armv7 iMX6Q)
> >> 
> >> 
> >> I'm looking for the following features:
> >> 
> >> (a) Install & remove a package
> >> (b) Install packages and its dependencies
> >> (c) Install a package with conflicts, such that the conflicting
> >> package is force removed
> >> (d) A local location with packages should serve as a package source
> >> (e) Remote server package (http file server based)
> >> (f) List of my packages installed
> >> (g) List of my packages not installed but available on the http file
> >> server
> >> (h) List of my packages that have updates (new version)
> >> (i) To be able to manage packages for multiple architectures (eg. rpm
> >> can produce packages for multiple architectures using one spec file)
> >> 
> >> 
> >> The above features will be invoked by the application GUI.
> >> Any suggestions: which package management solution would answer all
> >> the above use cases?
> >> 
> >> 
> >> 
> >> (e) I use smart + RPM. I have a remote package server setup via this in
> >> local.conf
> >> 
> >> FEED_DEPLOYDIR_BASE_URI = "http://packages.foo.bar"
> >> 
> >> Then I'm rsyncing the files up to the server after a bitbake
> >> package-index.
> >> 
> >> Then smart update / search / install
> >> 
> >> That seems to work well in my testing.
> > 
> > Hi Alex,
> > 
> > Thanks for inputs!
> > 
> > Is smart development stopped?
> > 
> > When I look at their mailing list it, the last posts were in Nov 2014.
> > It looks like no more development for smart package manager. I would
> > then tend to say that it will not be a right way for me.
> 
> I don't know. To me the question would be does it do want I need it to
> do as well as I need it to do it,
> rather than asking whether there is a lot of activity. One might take
> the view that if it is doing its job,
> a lack of activity is a sign that it's a mature piece of software that
> needs little further development.
> 
> You'll have to make that decision yourself.
> 
> My understanding is that smart is the recommended way to do things (at
> least it was what was
> recommended to me) - https://wiki.yoctoproject.org/wiki/Smart

FYI, here is some of the thinking that led to the decision to use smart:

https://lists.yoctoproject.org/pipermail/yocto/2012-October/010384.html

Of course that was a few years ago now - we probably ought to look at the RPM 
landscape again (e.g. DNF) and see if any change is warranted.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Embedded Linux Package Management

[Paul Eggleton]

On Friday 20 March 2015 11:10:39 Paul Eggleton wrote:
> On Friday 20 March 2015 11:26:43 Alex J Lennon wrote:
> > On 20/03/2015 11:15, Prasant J wrote:
> > > On Fri, Mar 20, 2015 at 2:21 PM, Alex J Lennon
> > > 
> > > <ajlennon@dynamicdevices.co.uk> wrote:
> > >> On 20/03/2015 09:34, Prasant J wrote:
> > >> 
> > >> Hi,
> > >> 
> > >> I'm looking for package management for my embedded linux systems
> > >> (yocto on armv7 iMX6Q)
> > >> 
> > >> 
> > >> I'm looking for the following features:
> > >> 
> > >> (a) Install & remove a package
> > >> (b) Install packages and its dependencies
> > >> (c) Install a package with conflicts, such that the conflicting
> > >> package is force removed
> > >> (d) A local location with packages should serve as a package source
> > >> (e) Remote server package (http file server based)
> > >> (f) List of my packages installed
> > >> (g) List of my packages not installed but available on the http file
> > >> server
> > >> (h) List of my packages that have updates (new version)
> > >> (i) To be able to manage packages for multiple architectures (eg. rpm
> > >> can produce packages for multiple architectures using one spec file)
> > >> 
> > >> 
> > >> The above features will be invoked by the application GUI.
> > >> Any suggestions: which package management solution would answer all
> > >> the above use cases?
> > >> 
> > >> 
> > >> 
> > >> (e) I use smart + RPM. I have a remote package server setup via this in
> > >> local.conf
> > >> 
> > >> FEED_DEPLOYDIR_BASE_URI = "http://packages.foo.bar"
> > >> 
> > >> Then I'm rsyncing the files up to the server after a bitbake
> > >> package-index.
> > >> 
> > >> Then smart update / search / install
> > >> 
> > >> That seems to work well in my testing.
> > > 
> > > Hi Alex,
> > > 
> > > Thanks for inputs!
> > > 
> > > Is smart development stopped?
> > > 
> > > When I look at their mailing list it, the last posts were in Nov 2014.
> > > It looks like no more development for smart package manager. I would
> > > then tend to say that it will not be a right way for me.
> > 
> > I don't know. To me the question would be does it do want I need it to
> > do as well as I need it to do it,
> > rather than asking whether there is a lot of activity. One might take
> > the view that if it is doing its job,
> > a lack of activity is a sign that it's a mature piece of software that
> > needs little further development.
> > 
> > You'll have to make that decision yourself.
> > 
> > My understanding is that smart is the recommended way to do things (at
> > least it was what was
> > recommended to me) - https://wiki.yoctoproject.org/wiki/Smart
> 
> FYI, here is some of the thinking that led to the decision to use smart:
> 
> https://lists.yoctoproject.org/pipermail/yocto/2012-October/010384.html
> 
> Of course that was a few years ago now - we probably ought to look at the
> RPM landscape again (e.g. DNF) and see if any change is warranted.

I forgot to mention, we do have some basic documentation here on
setting up a feed if you hadn't already seen it:

http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#using-runtime-package-management

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Embedded Linux Package Management

[Prasant J]

On Fri, Mar 20, 2015 at 4:44 PM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
> On Friday 20 March 2015 11:10:39 Paul Eggleton wrote:
>> On Friday 20 March 2015 11:26:43 Alex J Lennon wrote:
>> > On 20/03/2015 11:15, Prasant J wrote:
>> > > On Fri, Mar 20, 2015 at 2:21 PM, Alex J Lennon
>> >
>> > I don't know. To me the question would be does it do want I need it to
>> > do as well as I need it to do it,
>> > rather than asking whether there is a lot of activity. One might take
>> > the view that if it is doing its job,
>> > a lack of activity is a sign that it's a mature piece of software that
>> > needs little further development.
>> >
>> > You'll have to make that decision yourself.
>> >
>> > My understanding is that smart is the recommended way to do things (at
>> > least it was what was
>> > recommended to me) - https://wiki.yoctoproject.org/wiki/Smart

@Alex:
You are correct, it should be able to do what I need.
It did most of the things that I need.

But I'm not fine in using a package if the development has stopped.
Smart may stop development but other packages continue to develop.
It is important for me to know that the maintainer will continue to provide
compliance as other libraries are actively developed.


>>
>> FYI, here is some of the thinking that led to the decision to use smart:
>>
>> https://lists.yoctoproject.org/pipermail/yocto/2012-October/010384.html
>>
>> Of course that was a few years ago now - we probably ought to look at the
>> RPM landscape again (e.g. DNF) and see if any change is warranted.

@Paul:
This is a very important link for me. This posts points out that yum
will not be compatible with rpm ver 5.
This will be a problem for me as my imx6 yocto build uses rpm5. So
technically I cannot use yum.

>
> I forgot to mention, we do have some basic documentation here on
> setting up a feed if you hadn't already seen it:
>
> http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#using-runtime-package-management
>


Thanks for inputs. Would like to get more inputs from community.

Looks like Alex is successful and happy in using smart + rpm. I would
re-consider smart + rpm for my solution.

Anyone else using any other package management solution ?


Regards, Pj

Re: Embedded Linux Package Management

[Mark Hatle]

On 3/21/15 3:40 AM, Prasant J wrote:
> On Fri, Mar 20, 2015 at 4:44 PM, Paul Eggleton
> <paul.eggleton@linux.intel.com> wrote:
>> On Friday 20 March 2015 11:10:39 Paul Eggleton wrote:
>>> On Friday 20 March 2015 11:26:43 Alex J Lennon wrote:
>>>> On 20/03/2015 11:15, Prasant J wrote:
>>>>> On Fri, Mar 20, 2015 at 2:21 PM, Alex J Lennon
>>>>
>>>> I don't know. To me the question would be does it do want I need it to
>>>> do as well as I need it to do it,
>>>> rather than asking whether there is a lot of activity. One might take
>>>> the view that if it is doing its job,
>>>> a lack of activity is a sign that it's a mature piece of software that
>>>> needs little further development.
>>>>
>>>> You'll have to make that decision yourself.
>>>>
>>>> My understanding is that smart is the recommended way to do things (at
>>>> least it was what was
>>>> recommended to me) - https://wiki.yoctoproject.org/wiki/Smart
> 
> @Alex:
> You are correct, it should be able to do what I need.
> It did most of the things that I need.
> 
> But I'm not fine in using a package if the development has stopped.
> Smart may stop development but other packages continue to develop.
> It is important for me to know that the maintainer will continue to provide
> compliance as other libraries are actively developed.

This is an open source project.  The Yocto Project developers will do they're
best to stand behind the technology that has been selected and have plans to
continue to fix defects, improve (as appropriate), and continue to evaluate
options moving forward.  But at this time, SmartPM is still the best answer for
our present needs, when RPM is selected as the package type.

You are welcome to provide your own package management front end, and/or port
components like DNF into the environment.  There is nothing stopping you other
then time and resources (the same constrains we are under.)

We do welcome contributions and enhancements from community members, but don't
expect us to select technology on a whim.  Usually we have a good reason to
select something, community input, requirements from members, or simply
familiarity with the code.

The SmartPM project itself is on a downward swing, however it does everything we
need it to do.  (One exception would be DeltaRPM support.. but frankly it's been
a low priority for people for a while now...)  SmartPM also has the advantage
that it's python and small.  Some of the other technologies, such as Zypper were
tried, and failed due to the, IMHO, onerous requirements that it's support
libraries, such as Boost and libstdc++, put onto the environment.  YUM is simply
not easily compatible with RPM5 and their community had been actively hostile to
RPM5 development.  SmartPM was simple, fast, and easy to modify -- with a
community that didn't mind change.  (DNF did not yet, exist at the time of the
decision -- it was being discussed, but it's only been recently that it has
advanced to a point where it can be seriously investigated as a possible
alternative.)

Also if you don't like SmartPM/RPM, you can always use IPK.  But you will give
up some of the capabilities that RPM brings to the table.  (Note, I believe IPK
is a better solution for smaller environments, while RPM is a better solution
for medium to large environments.)

> 
>>>
>>> FYI, here is some of the thinking that led to the decision to use smart:
>>>
>>> https://lists.yoctoproject.org/pipermail/yocto/2012-October/010384.html
>>>
>>> Of course that was a few years ago now - we probably ought to look at the
>>> RPM landscape again (e.g. DNF) and see if any change is warranted.
> 
> @Paul:
> This is a very important link for me. This posts points out that yum
> will not be compatible with rpm ver 5.
> This will be a problem for me as my imx6 yocto build uses rpm5. So
> technically I cannot use yum.
> 
>>
>> I forgot to mention, we do have some basic documentation here on
>> setting up a feed if you hadn't already seen it:
>>
>> http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#using-runtime-package-management
>>
> 
> 
> Thanks for inputs. Would like to get more inputs from community.
> 
> Looks like Alex is successful and happy in using smart + rpm. I would
> re-consider smart + rpm for my solution.

I have no heard any serious complaints about SmartPM, other then concern of
community decline.  I use SmartPM/RPM5 (and intend to continue for the
forseeable future) in supporting on-target field upgrade solutions.  So far this
has turned out to be much easier to support and work on unique requirements my
customers have based on the simplicity of the Smart implementation.

--Mark

> Anyone else using any other package management solution ?
>
> 
> Regards, Pj
> 

Re: Embedded Linux Package Management

[Benjamin Esquivel]

Hi Prasant,

On Fri, 2015-03-20 at 11:14 +0000, Paul Eggleton wrote:
> On Friday 20 March 2015 11:10:39 Paul Eggleton wrote:
> > On Friday 20 March 2015 11:26:43 Alex J Lennon wrote:
> > > On 20/03/2015 11:15, Prasant J wrote:
> > > > On Fri, Mar 20, 2015 at 2:21 PM, Alex J Lennon
> > > > 
> > > > <ajlennon@dynamicdevices.co.uk> wrote:
> > > >> On 20/03/2015 09:34, Prasant J wrote:
> > > >> 
> > > >> Hi,
> > > >> 
> > > >> I'm looking for package management for my embedded linux systems
> > > >> (yocto on armv7 iMX6Q)
> > > >> 
> > > >> 
> > > >> I'm looking for the following features:
> > > >> 
> > > >> (a) Install & remove a package
> > > >> (b) Install packages and its dependencies
> > > >> (c) Install a package with conflicts, such that the conflicting
> > > >> package is force removed
> > > >> (d) A local location with packages should serve as a package source
> > > >> (e) Remote server package (http file server based)
> > > >> (f) List of my packages installed
> > > >> (g) List of my packages not installed but available on the http file
> > > >> server
> > > >> (h) List of my packages that have updates (new version)
> > > >> (i) To be able to manage packages for multiple architectures (eg. rpm
> > > >> can produce packages for multiple architectures using one spec file)
> > > >> 

This list of requirements you put seem very helpful from the package
management standpoint although I believe this can all be done in a
couple of scripting lines at the most, if you're with Yum/RPM anyway.

> > > >> 
> > > >> The above features will be invoked by the application GUI.
> > > >> Any suggestions: which package management solution would answer all
> > > >> the above use cases?
> > > >> 
> > > >> 
> > > >> 
> > > >> (e) I use smart + RPM. I have a remote package server setup via this in
> > > >> local.conf
> > > >> 
> > > >> FEED_DEPLOYDIR_BASE_URI = "http://packages.foo.bar"
> > > >> 
> > > >> Then I'm rsyncing the files up to the server after a bitbake
> > > >> package-index.
> > > >> 
> > > >> Then smart update / search / install
> > > >> 
> > > >> That seems to work well in my testing.
> > > > 
> > > > Hi Alex,
> > > > 
> > > > Thanks for inputs!
> > > > 
> > > > Is smart development stopped?
> > > > 
> > > > When I look at their mailing list it, the last posts were in Nov 2014.
> > > > It looks like no more development for smart package manager. I would
> > > > then tend to say that it will not be a right way for me.
> > > 
> > > I don't know. To me the question would be does it do want I need it to
> > > do as well as I need it to do it,
> > > rather than asking whether there is a lot of activity. One might take
> > > the view that if it is doing its job,
> > > a lack of activity is a sign that it's a mature piece of software that
> > > needs little further development.
> > > 
> > > You'll have to make that decision yourself.
> > > 
> > > My understanding is that smart is the recommended way to do things (at
> > > least it was what was
> > > recommended to me) - https://wiki.yoctoproject.org/wiki/Smart
> > 
> > FYI, here is some of the thinking that led to the decision to use smart:
> > 
> > https://lists.yoctoproject.org/pipermail/yocto/2012-October/010384.html
> > 
> > Of course that was a few years ago now - we probably ought to look at the
> > RPM landscape again (e.g. DNF) and see if any change is warranted.
> 
> I forgot to mention, we do have some basic documentation here on
> setting up a feed if you hadn't already seen it:
> 
> http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#using-runtime-package-management
> 
> Cheers,
> Paul
> 
> -- 
> 
> Paul Eggleton
> Intel Open Source Technology Centre