Mailing List Archive

Kfir Lavi wrote:
> Do we have a tool that can manage a binary packages that we prepare
> in advance for the target system?

Check out qmerge in app-portage/portage-utils.


//Peter

On Thursday, December 16, 2010 07:14:55 Peter Stuge wrote:
> Kfir Lavi wrote:
> > Do we have a tool that can manage a binary packages that we prepare
> > in advance for the target system?
>
> Check out qmerge in app-portage/portage-utils.

i think that's the only thing we have so far. it could probably use some
polishing ... perhaps we should put together a list of things people could
contribute to.
-mike

On Thu, Dec 16, 2010 at 4:12 PM, Mike Frysinger <vapier@gentoo.org> wrote:

> On Thursday, December 16, 2010 07:14:55 Peter Stuge wrote:
> > Kfir Lavi wrote:
> > > Do we have a tool that can manage a binary packages that we prepare
> > > in advance for the target system?
> >
> > Check out qmerge in app-portage/portage-utils.
>
> i think that's the only thing we have so far. it could probably use some
> polishing ... perhaps we should put together a list of things people could
> contribute to.
> -mike
>

I'll be happy to help.

Kfir

On Thu, Dec 16, 2010 at 5:19 PM, Kfir Lavi <lavi.kfir@gmail.com> wrote:

>
>
> On Thu, Dec 16, 2010 at 4:12 PM, Mike Frysinger <vapier@gentoo.org> wrote:
>
>> On Thursday, December 16, 2010 07:14:55 Peter Stuge wrote:
>> > Kfir Lavi wrote:
>> > > Do we have a tool that can manage a binary packages that we prepare
>> > > in advance for the target system?
>> >
>> > Check out qmerge in app-portage/portage-utils.
>>
>> i think that's the only thing we have so far. it could probably use some
>> polishing ... perhaps we should put together a list of things people could
>> contribute to.
>> -mike
>>
>
> I'll be happy to help.
>
> Kfir
>
What was the aim of creating portage-utils?

Regards,
Kfir

On Thursday, December 16, 2010 10:44:20 Kfir Lavi wrote:
> What was the aim of creating portage-utils?

goals:
- small
- fast
- little to no dependencies
- should require only modern C compiler & library
- support binary packages
- fully compatible with official Gentoo PM (i.e. portage
- have fun

basically we deem python and friends to be way too heavy for embedded systems
where most of the time you just want to install/update binary packages. there
is no desire at all to have portage-utils build packages from source.
-mike

Hello

In my embedded system,the goal is small disk usage, so up to now i have been
using qtbz2 -t and then manualy removing documentation, man pages, header
files and static libraries.
So i will be glad if a new system will be configurable to filter it
appropriately.

Thanks

Jakub

Dne čtvrtek 16 Prosinec 2010 18:17:48 Mike Frysinger napsal(a):
> On Thursday, December 16, 2010 10:44:20 Kfir Lavi wrote:
> > What was the aim of creating portage-utils?
>
> goals:
> - small
> - fast
> - little to no dependencies
> - should require only modern C compiler & library
> - support binary packages
> - fully compatible with official Gentoo PM (i.e. portage
> - have fun
>
> basically we deem python and friends to be way too heavy for embedded
> systems where most of the time you just want to install/update binary
> packages. there is no desire at all to have portage-utils build packages
> from source. -mike

Jakub Ladman wrote:
> In my embedded system,the goal is small disk usage, so up to now i
> have been using qtbz2 -t and then manualy removing documentation,
> man pages, header files and static libraries.
> So i will be glad if a new system will be configurable to filter it
> appropriately.

That would be the INSTALL_MASK setting during emerge. I don't think
filtering should be done at install time.


//Peter

On Fri, Dec 17, 2010 at 1:29 PM, Jakub Ladman <ladmanj@volny.cz> wrote:

> Hello
>
> In my embedded system,the goal is small disk usage, so up to now i have
> been
> using qtbz2 -t and then manualy removing documentation, man pages, header
> files and static libraries.
> So i will be glad if a new system will be configurable to filter it
> appropriately.
>

Thanks
>
> Jakub
>
I guess that the embedded system should include /etc/make.conf and we'll use
the FEATURES to know what to do. The first thing will be to support the
noman noinfo nodoc features
This will keep us close to the convention of Gentoo.

>
> Dne čtvrtek 16 Prosinec 2010 18:17:48 Mike Frysinger napsal(a):
> > On Thursday, December 16, 2010 10:44:20 Kfir Lavi wrote:
> > > What was the aim of creating portage-utils?
> >
> > goals:
> > - small
> > - fast
> > - little to no dependencies
> > - should require only modern C compiler & library
> > - support binary packages
> > - fully compatible with official Gentoo PM (i.e. portage
> > - have fun
> >
> > basically we deem python and friends to be way too heavy for embedded
> > systems where most of the time you just want to install/update binary
> > packages. there is no desire at all to have portage-utils build packages
> > from source. -mike
>
>

On Fri, Dec 17, 2010 at 5:36 PM, Peter Stuge <peter@stuge.se> wrote:

> Jakub Ladman wrote:
> > In my embedded system,the goal is small disk usage, so up to now i
> > have been using qtbz2 -t and then manualy removing documentation,
> > man pages, header files and static libraries.
> > So i will be glad if a new system will be configurable to filter it
> > appropriately.
>
> That would be the INSTALL_MASK setting during emerge. I don't think
> filtering should be done at install time.
>
>
> //Peter
>
> noman feature prevent man install to the target system, but the package
created still contain the man pages.
So if we want to install a bin package in a running target system, man pages
will be installed too.
Why the features noman nodoc noinfo don't influance the creation of binpkg
without them?

Regards,
Kfir

On Friday, December 17, 2010 10:36:44 Peter Stuge wrote:
> Jakub Ladman wrote:
> > In my embedded system,the goal is small disk usage, so up to now i
> > have been using qtbz2 -t and then manualy removing documentation,
> > man pages, header files and static libraries.
> > So i will be glad if a new system will be configurable to filter it
> > appropriately.
>
> That would be the INSTALL_MASK setting during emerge. I don't think
> filtering should be done at install time.

current convention is to have everything in the binary package and do the file
removal (INSTALL_MASK/noman/etc...) at install time. i dont see much reason
to change this as it keeps the src_* and pkg_* steps cleanly separated.
-mike