Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Thu 18 Dec 2014, 23:19
All times are UTC - 4
 Forum index » Taking the Puppy out for a walk » Suggestions
Woof-CE could tidy up automatically after building a Puppy
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 1 of 1 [10 Posts]  
Author Message
stemsee

Joined: 27 Jun 2013
Posts: 669
Location: London

PostPosted: Fri 20 Jun 2014, 08:04    Post subject:  Woof-CE could tidy up automatically after building a Puppy  

Woof-CE kernel-kit builds a headers package, then either a kernel and modules package, or kernel with modules package. The aufs-utils are bundled with the modules. It seems to me that the headers shouldn't be packaged as a separate sfs, but they should be bundled with the devx, and also the kernel sources.sfs. This is one of the things that get me with puppy - the true size of a useful puppy is disguised, the size is hidden in the related packages, devx, headers, sources, and apps.sfs, That is why I built EmSee-linux 2-3GB pups, because it includes the undisguised size of a useful pup. Now, I build several pups and kernels per month, there is a lot of manual work involved even when using kernel kit. And there are lots of packages and folders here and there. After compiling four kernels, 2x 64bit and 2x 32 bit, aufs-utils don't get compiled because build script doesn't forcefully overwrite previous one when the folder is left in existence. Also in order to use your kernel and modules package (which gets converted to sfs for use with...?) in woof-ce, you need to manually convert to a pet and copy or move it to the local repositories. So you have a sources.sfs and sources dir = 1.3 GB sitting on the disc doing nothing (x4). No wonder I get mucking fuddled! I am not complaining i am just moaning. There needs to be a tidying up function at the end of the script to sort all of this out, to move all packeted stuff out and delete the debris. I don't know where else to say this so I said it here. I do know that all of this will be unified in woof-next at some point, but in the mean time it won't require much typing to make the changes. Unfortunately git doesn't work well on my system, or I don't know how to push to testing from my laptop, it is not as though I didn't try. I did!
Back to top
View user's profile Send private message MSN Messenger 
01micko


Joined: 11 Oct 2008
Posts: 7841
Location: qld

PostPosted: Fri 20 Jun 2014, 09:14    Post subject:  

Join in the fun here!

Wink

_________________
Woof Mailing List | keep the faith Cool |
Back to top
View user's profile Send private message Visit poster's website 
stemsee

Joined: 27 Jun 2013
Posts: 669
Location: London

PostPosted: Tue 01 Jul 2014, 13:28    Post subject:  

'./build.sh clean' will do nicely thank you! I like Draconian measures!! Wink

Can I suggest moving headers /usr/include to kernel modules for safekeeping, as default. As woof-ng kernel combo is proving to have a much wider use than just for puppy. I envision booting any squashfs live package with it, and then one would, I assume, need native development libraries, rather than puppy devx.sfs, which means having headers with kernel combo in nearly all circumstances is preferable, Also when building a woof-ng distro there is no option to import the headers package, except they are copied to chroot or root-fs-skeleton (or whatever it's called now.) adding a degree of extra difficulty for novices. But for devs it will be easy to move the headers out of modules.sfs and implant wherever!
Back to top
View user's profile Send private message MSN Messenger 
01micko


Joined: 11 Oct 2008
Posts: 7841
Location: qld

PostPosted: Tue 01 Jul 2014, 18:03    Post subject:  

Headers belong with development files, not the kernel source.

Did you know many programs will not compile without linux headers.

And why subject users to the bloat of the kernel source when they don't need it. It is only needed for compiling modules.

_________________
Woof Mailing List | keep the faith Cool |
Back to top
View user's profile Send private message Visit poster's website 
stemsee

Joined: 27 Jun 2013
Posts: 669
Location: London

PostPosted: Wed 02 Jul 2014, 01:43    Post subject:  

I didn't know the technical issues, just thinking of the immediate convenience when looking at them in /dist/packages folder! So are they not available to the system from kernel-modules.sfs?
Back to top
View user's profile Send private message MSN Messenger 
SFR


Joined: 26 Oct 2011
Posts: 1111

PostPosted: Wed 02 Jul 2014, 12:46    Post subject:  

01micko wrote:
Headers belong with development files, not the kernel source.

Just to be sure: let's say I compile a different kernel and replace zdrv.sfs.
Then it would be a wise move to also replace the headers in devx.sfs, in order to have a 100% proper, complete enviroment?

Greetings!

_________________
[O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource
Omnia mea mecum porto.
Back to top
View user's profile Send private message 
01micko


Joined: 11 Oct 2008
Posts: 7841
Location: qld

PostPosted: Wed 02 Jul 2014, 18:05    Post subject:  

SFR wrote:
Just to be sure: let's say I compile a different kernel and replace zdrv.sfs.
Then it would be a wise move to also replace the headers in devx.sfs, in order to have a 100% proper, complete enviroment?

Greetings!


Yes, that is best practice. However the headers don't change a lot and if kernel versions are reasonably close it often doesn't matter. Lazy man's way would be simply install the headers pet which will be on the top layer covering the old devx version. Depends on whether you want to make an iso to ship it as a puplet or just tinkering around for personal use.

One example where they were needed (and not kernel source) was when I compiled abiword for 64 bit. I forgot to install headers at the woof level and consequently ./configure didn't even complete. I installed a wrong version (just because it was handy) and abiword compiled fine. Of course most userspace progs are not kernel version dependent.

An instance of where headers did matter (version) was building AMD video driver. As you know they lag 4 or 5 versions of the kernel behind, so it wouldn't compile. Kernel devs changed the location of version.h ( I forget where for now ) but I made a symlink to where AMD wanted it and the driver compiled. Old headers would not suffice even though version.h would have been in the correct place.

So, it is the responsibility of the distro builder/maintainer to ensure correct version headers are installed when shipping and the user if they change kernels.

_________________
Woof Mailing List | keep the faith Cool |
Back to top
View user's profile Send private message Visit poster's website 
stemsee

Joined: 27 Jun 2013
Posts: 669
Location: London

PostPosted: Thu 03 Jul 2014, 05:07    Post subject:  

I for my part see no better way to deal with headers than to put them in with modules.sfs, possibly compressed, WHEN merely providing a kernel combo update, but in the case of a new distro to package them in devx! Can anyone foresee any critical conflicts! Which layer takes precedence?

Edit: or bundled as a pet as 01micko suggested. So that would need to be added to build.sh
Back to top
View user's profile Send private message MSN Messenger 
jamesbond

Joined: 26 Feb 2007
Posts: 2232
Location: The Blue Marble

PostPosted: Fri 04 Jul 2014, 00:36    Post subject:  

There are two kinds of the kernel headers.

1. libc kernel headers (also known as "userspace kernel headers" - yes, an oxymoron I know). This is what you get with "make headers_install". These are used to build applications and libc.
2. the real kernel headers (the one used for building kernel modules) - this is a subset of kernel source.

---

(1) does not have to match the version of the running kernel. See: https://sourceware.org/glibc/wiki/FAQ#What_version_of_the_Linux_kernel_headers_should_be_used.3F. So it doesn't belong in modules.sfs, it should live in devx (because it doesn't depend on kernel version anyway and it is mostly needed for compiling apps).

Puppy never has (2), instead it always packs the *entire* kernel source. And packing the 100MMB of kernel source to modules.sfs doesn't make a lot of sense.

You can of course makes (2) yourself but there isn't an easy way to do so; and when you do, it makes sense to put it as part of modules.sfs to make it easier for other people to compile new kernel modules - but again the question from Mick is - how many people actually *builds* kernel modules?

_________________
Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread
Back to top
View user's profile Send private message 
stemsee

Joined: 27 Jun 2013
Posts: 669
Location: London

PostPosted: Fri 04 Jul 2014, 07:51    Post subject:  

@jamesbond

Thanks for sharing knowledge! I now know three times more about headers today as I did yesterday!

"Who can count what is lacking?"
Back to top
View user's profile Send private message MSN Messenger 
Display posts from previous:   Sort by:   
Page 1 of 1 [10 Posts]  
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Taking the Puppy out for a walk » Suggestions
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0713s ][ Queries: 11 (0.0045s) ][ GZIP on ]