Ummm. I'm not sure if I follow you. $ make will build the objects and stuff in the current path of your source tree. $ make install copies the executables to the system usable locations. /usr/bin/ /lib/modules/..... /usr/share/doc/..... (which is why you need to be root in a lot of cases to run make install, but not to run make) A package maintainer will likely use stuff like what's in debian/rules debian/binary and such to build a package manager package, instead of using make install to place the important components (results) where they need to be. A package manager package lets you keep track of what got installed and where and the package provides additional features useful for long term maintenance and/or large scale deployment. If you want to build a package (i.e. .deb) you'd use those tools for that to do that. Otherwise you have to at least mimic make install. Which is a bit futile IMO, given that you could just run make install. i.e. how exactly would you create your tarball? From a diff of an entire backup before and after make install? By doing everything done by make install manually? That's fine for relatively small things like alsa. But for X, KDE, ???, and other more bulky entities. You'd need a couple lifetimes of spare time to re-invent make install. And scons install and .... and ... and ... Also bear in mind that if you're building something on a system other than the one where it will be deployed. You will run into some version compatibility issues. Just a minor difference in the API between version 1.0.24 and 1.0.25 could make things unusable. And as previously mentioned, alsa comes with the 2.6 kernel, so you'll have an existing version already in place that you will need to deal with, one way or another. When there's multiple versions of things, at runtime things like to load in alphabetical order or ascii order at least. Which generally means the that OLDer version takes priority. So even if you install your newer version, it's probably going to be ignored unless you remove or replace the older version. The manual approach to dependency hell I guess, of sorts. Lots of little things that will keep you from succeeding. It's probably time better spent learning an existing package management system IMO. Than to create your own. Especially if you're on your own and not part of team. But it's almost all open source so if you can read the source, everything that you need to know is there in one form or another. - James On 6/20/11, David Henderson <dhenderson@xxxxxxxxxxxxxxxx> wrote: > On 06/20/2011 11:52 AM, Pierre Lorenzon wrote: >> Hi, >> >> >> >> From: David Henderson<dhenderson@xxxxxxxxxxxxxxxx> >> Subject: Re: First post >> Date: Sun, 19 Jun 2011 15:28:48 -0400 >> >>> Thanks for the reply Pierre. I checked into the blfs book, but >>> it merely says "these five chapters will cover alsa" and then >>> gives you a basic "type configure&& make". This is obviously >>> not going to answer the questions below. :) Any other thoughts? >>> >>> Dave >>> >>> >>> On 06/19/2011 11:22 PM, Pierre Lorenzon wrote: >>>> Hi, >>>> >>>> It looks like to me such questions are well answered in the >>>> blfs book. I personnaly think that the latter is a very good >>>> tool to build his own custom distro. >>>> >>>> Bests >>>> >>>> Pierre >>>> >>>> >>>> From: David Henderson<dhenderson@xxxxxxxxxxxxxxxx> >>>> Subject: First post >>>> Date: Sun, 19 Jun 2011 14:41:08 -0400 >>>> >>>>> Hi everyone! I'm currently expanding my knowledge of GNU/Linux >>>>> to >>>>> include building packages from scratch towards an overall goal >>>>> of a >>>>> custom distro. So far, I have a nice base for a command line >>>>> OS, but >>>>> want to expand into the multimedia aspect. Alsa was my first >>>>> (only?) >>>>> choice for the audio portion, but I'm running into problems. >>>>> The alsa >>>>> site is somewhat overwhelming to newbies and is easy to get >>>>> lost. I >>>>> have a few questions below from which I hope I can find help. >>>>> All >>>>> contributions are greatly appreciated. :) >>>>> >>>>> Thanks, >>>>> Dave >>>>> >>>>> >>>>> 1) Currently I have downloaded alsa-driver, alsa-lib, and >>>>> alsa-utils >>>>> packages. Is there an order in which these packages need to be >>>>> compiled >>>>> and installed? >> This question is answered by the blfs book. First alsa-lib >> and after alsa-utils. >> >> >> >>>>> 2) I'm currently running the relatively new Linux kernel 2.6.33 >>>>> so do I >>>>> need the alsa-driver package? >> No ! I am running a 2.6.32 kernel and never installed >> alsa-driver. Anyway if the sound system is something very >> exotic it might be necessary ... >> >> >> > > Great one less thing to compile! :) > >>>>> 3) I've been able to successfully compile the alsa-lib package >>>>> and >>>>> install it in the custom distro. When I try to compile the >>>>> alsa-utils >>>>> package, I constantly get the error: >>>>> >>>>> checking for libasound headers version>= 1.0.16... not present. >>>>> configure: error: Sufficiently new version of libasound not >>>>> found. >>>>> >>>>> I'm actually using an existing Kubuntu installation to build >>>>> the >>>>> packages for my custom distro. As a result, after I compiled >>>>> the newer >>>>> alsa-lib, I didn't install the package into the Kubuntu OS, but >>>>> rather a >>>>> staging directory (/opt/staging/alsa). I'm sure the reason >>>>> this is >>>>> failing is because it's probably looking for /usr/lib/... or >>>>> some other >>>>> default location. How do I tell the configure script for the >>>>> alsa-utils >>>>> to look in the staging directory for the header files it needs? >> Humm ! I don't really understand this method. In my opinion >> if you want to have a custom distro you first install a >> basic systme on a partition or in a directory. Once the >> basic system is installed (more or less the content of the >> lfs book) you simply chroot to this new system to install >> the rest of the stuff. Following this scheme there will be >> no problem. I did it many times ! >> >> It leads me to a more global question : you say you want to >> build a custom distro but do you have some kind of >> documentation to do that ? If you plan to do that on your >> own, it's a big deal ! Anyway I'll suggest you to have a >> look at the lfs book. It might be that the installation >> schedule suggested by the lfs team is not suitable for you >> but in my opinion it is better to check this point before >> "reinventing the weel" as we say in french ! >> >> >> Bests >> >> Pierre >> > > I guess the best way to describe what I'm trying to accomplish would be > to look at it from a package maintainers perspective. They have to > compile the source code into a staging directory so they can package the > software. If they just ran the normal "configure && make && make > install", how would they know what files to include in the software > package as they get spread through the FS? There has to be a staging > directory that contains everything in isolation so that the package > maintainer doesn't have to do so much overhead just to create a package, > but when the package is installed, it works correctly (hence using > DESTDIR and not --prefix). The problem I'm having, as stated, is that I > think alsa is looking for header files or whatever under normal > installation directories (e.g. /usr/... or /usr/local/...), but I need > it to look under the staging directory (/opt/staging/alsa) since that's > where the other matching compiled packages of alsa reside. Any thoughts > to accomplish this? In other words, what are the compile parameters a > package maintainer includes to compile alsa? > > Thanks, > Dave > > ------------------------------------------------------------------------------ > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > _______________________________________________ > Alsa-user mailing list > Alsa-user@xxxxxxxxxxxxxxxxxxxxx > https://lists.sourceforge.net/lists/listinfo/alsa-user > ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Alsa-user mailing list Alsa-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-user
