Re: rolling your own package management

On 06/27/2012 01:59 PM, LM wrote:
> Eric Herman wrote:
>> To make life better for myself, I added an "ldconfig" user to Matthias
>> Beckmann's original plan, and my friend (who goes by Random) did a nice
>> job of pulling both of our mods into a gentle fork, which is mirrored here:
>>
>> https://github.com/ericherman/package-users
>
> Thanks for the link.
>
> Does this scale well when you have lots of packages?

I suppose that depends on what you mean by "lots", but I use it for my 
desktop systems, so yes, I would say yes. At the moment, as I have 
recently rebuilt my desktop, I have only 215-or-so packages installed.

(counting xorg as a single package)


if you grab:

wget logicgate.nl/eric/dload/eric-pkgusr-options-20120612.tar.xz

You'll get a tarball containing the "options" files for all of the 
packages I have installed. You'll see that most of them are not very 
interesting ... basicaly "configure --prefix=/usr" and "make" and "make 
check" and "make install" .... some have a lot more command line args, 
take a look.

also I did a "forall_direntries_from openssl" and included the output to 
a file included in the tarball.

>
> I'm rereading http://www.linuxfromscratch.org/hints/downloads/files/more_control_and_pkg_man.txt
> and it sounds like you have to make sure the makefile doesn't perform
> certain functions during install (like install to a non-install
> directory or mess with permissions).  What are your experiences with
> going through and changing the makefiles (configure, cmake scripts,
> etc.) to handle this?  Do you have to redo the patches/fixes you make
> for these situations each time you upgrade to a newer version of the
> software?
>
> As I'm building various programs (on different operating systems), I'm
> hitting lots of situations where the makefiles fail and I'm ending up
> with lots of patches just to get programs to build properly.  Been
> trying to use the DESTDIR variable to install to directories I want.
> However, some applications don't honor it.  Some applications have the
> compiler name hard-coded.  Might be fine if you're always using gcc,
> but what if you want to use lsbcc instead?  Also having issues with
> programs installing files all over the place.  Some put files under
> their own directories like openssl (I ended up with a \usr\local\ssl
> directory) and some put files in etc. or /usr/local/etc.  Files also
> end up all over the place under share (some in pixmaps, some under the
> application name, some under doc and some under html).  Would like to
> organize for consistent file locations for applications, but not sure
> what to put where.  I've reread the FHS information several times and
> still have lots of questions on where things should go or shouldn't
> that aren't answered by the document.  How do you handle organizing
> some of this?  For instance, am curious what directories your openssl
> files ended up in.


With one or two exceptions, I don't do patches at all.

When there's a snag in a package, usually someone else has found and 
solved it before me. I am able to use the instructions in "Beyond Linux 
 From Scratch" or the instructions in "Community Driven BLFS" as a 
starting point for almost everything.

http://www.linuxfromscratch.org/blfs/view/svn/
http://cblfs.cross-lfs.org/index.php/Main_Page


 From these projects, I have learned that almost all ./configure scripts 
allow me to set a "--prefix" and (if needed) other directories, so I'm 
able to handle *almost* everything in command, without a patch.

As for changing permissions and such, the wrapper scripts for "chgrp", 
"chmod", "chown", "install", and "mkdir" provided in package-users 
simply prevent the existing makefiles from messing with permissions.

Sometimes I have to update the instructions, especially if I'm trying to 
build a toolchain newer than LFS or CLFS has published, but most of the 
time, someone else has gotten their first.


As for cross-compiling complete systems in conjunction with 
package-users, I don't have direct experience here.  I have used Cross 
LFS to build an initial bootable MIPS system from an x86 system, then 
done the remainder of the build native on the MIPS system. I have not 
tried using "package users" to build a complete system from a cross 
compiler.


Cheers,
  -Eric






>
>> I have come to really appreciate this approach, but I know that other
>> approaches (like actually building .deb/.rpm or variations on the
>> "forest of symlinks" approach) are more in-keeping with traditional
>> distros, and that makes an LFS system a little less alien, but from your
>> comments I suspect you're willing to be a bit alien.
>
> I'm definitely not thrilled with the .deb or .rpm approach.  I want to
> automate the build and installation process as much as possible and
> from everything I've read, it sounds like the process to initially
> create the .deb or .rpm is anything but automated.  You're basically
> automating it for the end user.  I'd definitely like to look into
> other systems even if they're not standard and find the best approach
> for my own needs.  Thanks very much for the information you supplied.
>
> Sincerely,
> Laura


-- 
http://www.freesa.org/ -- mobile: +31 620719662
aim: ericigps -- skype: eric_herman -- jabber: [email protected]
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-chat
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page