Re: Format for the future LFS
Gerard Beekmans wrote: > > If at the end of the day the current DocBook setup can no longer deliver > what we need, and nobody can find a way to make it work, then we'll have > to do what it takes to get the job done. Staying with > DocBook/XML/whatever is never a requirement. We'll use what we need to. > > G Most likely it wouldn't support the multiple options, as it's currently implemented. Making a DTD segment for each pm and having each pm tagged appropriately would enable keeping most of the current text intact. Since it's an XML format, one DTD for basic structure, with additional DTD for the different pms / other modules as selected. [ figuring the modular, custom book idea. ] If the user selects to use dpkg, then a small bit if DTD is added into the document headers to define th dpkg specific code blocks. The only issue is that the book sources will be much larger, having a section for each difference being supported. Using CSS to style the sections, can be one css for all versions, since if a particular item is never called it just gets ignored by the user agent. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Package Management - technical comparisons
TheOldFellow wrote: > On Tue, 04 Mar 2008 22:11:53 -0700 > Gerard Beekmans <[EMAIL PROTECTED]> wrote: > >> The more we discuss it, the more PM becomes a focal point. I agree with >> Greg Schafer in that the actual choice of PM is a user's choice in the >> end and shouldn't matter. >> >> About all we should attempt to do is inform the user of all the main >> stream and (perhaps) some of the not-so-mainstream options out there. > > I really do disagree with this stance. As an educative, as well as > practical project, we should show at least one worked example. Just > like we do with SysVInit and the bootscripts (which several of us > don't ever use any more). I hate to say it, but I'm forced to agree with you, *if* the flat book remains. Like SysVinit, bootscritpts, and sysklod, it should be easy to break away from the basic and make a choice, but that's getting ahead of ourselves (please ream my response to Alexander's post which probably steps on Gerard's request too, but I happened to read Alexander's first). I'll give a response to Gerard's too, but It'll be more detailed and have to wait till tomorrow, I have to get up in 4 hours. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Package Management - technical comparisons
DJ Lucas wrote: > please ream my response *read LOL, and on that note, good night. -- DJ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Format for the future LFS
2008/3/5, Gerard Beekmans <[EMAIL PROTECTED]>: > Jeremy relayed an idea in one of his emails that I brought up again. > Maybe you didn't see it, or maybe it just doesn't apply to the question > you posted. In which case, can you clarify what you are after as I must > have misunderstood. I am after the need to identify what pieces of information need to constitute the output. The input of the dynamic website is currently defined better than the output. > A few years ago we had an idea that creates custom books for people > on-the-fly. The idea behind it being you end up with a book that is > tailored to your needs. Somewhere on the website you select from a list > of pre-defined modules if you will. The answers to those questions (ie: > do you want to add a Package Manager) would result in a book with > additional instructions (ie a bash RPM patch if you chose RPM, or a > other-package DPKG patch) or potentially instructions removed. Yes, that's right. However, the idea never went behind "we have to generate the content dynamically", and nobody provided even a single page of the modified book. So it looks a bit abstract to me. > This idea didn't come to fruition mostly due to server resource > limitations. That problem shouldn't exist anymore nowadays. Here I am not sure whether I agree about the reason, but this disagreement is off-topic for this thread. I want the idea to be clarified by providing samples how the generated content should look like, in terms of HTML layout. Such samples would help us classify the replaceable/optional items and thus avoid redesigning the generator more times than it is needed. > If at the end of the day the current DocBook setup can no longer deliver > what we need, and nobody can find a way to make it work, then we'll have > to do what it takes to get the job done. Staying with > DocBook/XML/whatever is never a requirement. We'll use what we need to. Yes, investigating the possibilities is the subject of this thread. But, unlike your previous thread, we have a constraint on the output here: it is HTML. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Format for the future LFS
2008/3/5, DJ Lucas <[EMAIL PROTECTED]>: > Alexander E. Patrakov wrote: > > > > So, please express your ideas in the following areas: > > > > > First and foremost, SLOW DOWN How about some baby steps instead of > leaps and bounds. The recent threads are going nowhere because we have > 20 individual topics crammed into one thread. There have been 4 now > that have all resulted in no clear direction. DESTDIR sounds like a > logical first step. I've excluded the rest of your message as it > doesn't seem useful just yet. Again, knowing nothing about the various > PMs, I've made some assumptions. Can someone confirm or deny those for me? Let's try. It is good that you don't forget that there are people that think that DESTDIR is a wrong approach, and also note the fact that most non-DESTDIR approaches can be applied to the corrent book without the need for such extensive modifications. > For RPM, I've made the assumption that you take a spec file and a source > tarball, and create an installable binary package, then install that > package. I don't suppose that the second step is automated only by rpm > itself, so the installation portion is different. I expect that, but > are the configure, make, make install commands the same for all DESTDIR > methods? Looking at different PMs, how much will be in common WRT to > CMMI? I'd say, 90% if you avoid RPM-specific idioms. You can look at my spec files in the "RPM: proof of concept" mail and see yourself. > On DESTDIR installs, DESTDIR can be an exported environment variable and > the target cleaned out after every installation is completed. This may interfere with the way Makefiles get environment variables. > If that > is possible, then the no PM group, the install-watch group, and the > timestamp group are completeley unaffected by the changes for a mass > majority of the packages as DESTDIR="". I'm looking for simplicity in > common instructions first. Again, take some baby steps, one thing at a > time. Lets try not make things so complicated just yet. If the above > handles getting DESTDIR into the current book, with such simplicity, > then get that part done first. Explicitly set DESTDIR="" for the first > cut and the book still works as is. If not, then if you would be so > kind as to explain away my assumptions, it'd be much appreciated by me > for certain, but would help in educating the rest of the readers as well > WRT RPM anyway. Also, the same goes for other DESTDIR PMs that anybody > would care to explain. Yes, DIY uses this fact. They require the reader to set $PM_DEST to an empty (no PM) or non-empty (PM) value, and run things like "make DESTDIR=$PM_DEST install". However, for some packages, this may need a command like "mkdir -p $PM_DEST/etc" before this. Also note that post-installation steps are required in all DESTDIR-based methods (e.g., to register info documentation correctly), and that all configuration files have to be marked as such in order to avoid their overwriting. "DESTDIR alone" is just broken, so a baby step leads to a hole in the ground. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Package Management - technical comparisons
2008/3/5, Gerard Beekmans <[EMAIL PROTECTED]>:
> The more we discuss it, the more PM becomes a focal point. I agree with
> Greg Schafer in that the actual choice of PM is a user's choice in the
> end and shouldn't matter.
Correct.
> About all we should attempt to do is inform the user of all the main
> stream and (perhaps) some of the not-so-mainstream options out there.
Currently we do exactly that on the
http://www.linuxfromscratch.org/lfs/view/development/chapter06/pkgmgt.html
page--yet it is useless, because one of the mainstream methods of
package management (DESTDIR-based) currently requires a lot of
deviation, and nothing is done to cover the topics of handling
configuration files and distributing the packages, if applicable.
> We need a clearly defined list of pros, cons and technical explanations
> plus their limitations of each viable choice - all the information that
> a user needs to make an informed decision while keeping in mind that
> some of these programs may never have been used (or heard of) before. So
> we can't assume a basic working understanding of the programs.
Correct.
> Having said that, we will probably get to a scenario where we need to
> settle on something we will be using ourselves for the LFS project. For
> instance, the LFS server itself will eventually be outfitted with one of
> the results of this process. This wouldn't be an endorsement, but will
> probably be perceived as such - "if the LFS developers use
> implementation X on the LFS server and to develop the LFS project itself
> with, then I should probably use it as well."
There is another argument. If there is no package manager in the book
that is required to be used by the editors (just some allegedly
PM-aware instructions), they will continue using the "it's all in my
head" principle and will have no motivation to check the modifications
supposed to make their pages PM-aware.
> One could consider embarking on a mission to make all the PM options
> talk to each other so you can mix and match what PM you use at any given
> time - you can switch from deb to rpm to something else on the same
> system on-the-fly. That would be an interesting challenge in itself.
Database conversion is, indeed, not a trivial task.
> Alexander started a thread about an RPM Proof Of Concept. I quickly
> glanced at it and it seems an installation HOWTO, not including the
> information I mentioned above that we need more than the installation
> itself right now.
The idea was to say something concrete. This is, of course, just a
skeleton, that has to be wrapped into some nice textual instructions
and explanations. We can't have the description of the build procedure
without something to describe. See also my "Format for the future LFS"
mail.
> If you feel you can talk about a potential PM candidate for LFS, please
> write up a document that outlines the following:
OK, let me start by talking about RPM 5.0.x, as released on
http://rpm5.org/. Note that this information doesn't apply to RPM 4.x,
as released on http://www.rpm.org/, i.e., there are two projects with
the same name and I am talking only about one of them. Also note that
I don't think it is the best alternative, I have not explored Pacman
enough to choose between them.
> - it's strengths and weaknesses
+ It (or its sibling, RPM 4.x) is used in a number of distributions
and thus receives a lot of testing.
+ It doesn't need a lot of external dependencies, and is simple enough
for a user to submit a working hint in the past.
+ It has all features that one expects from a working package manager,
e.g., sane handling of the configuration files and dependency
checking.
+ It allows to build the package as non-root, and run only the actual
package installation command (rpm -ivh) as root. I.e., the correct
permissions are specified in the spec file.
+ It allows arbitrary steps to be taken (e.g., stripping, compression
of man and info pages, catching obvious errors such as /usr/etc and
UTF-8 encoded manual pages) automatically before creating a binary
package
+ It manipulates binary packages, with obvious benefits like the
ability to deploy them, to revert to the old version quickly, and so
on
+ Packaging and build instructions are in one file, with the .spec
extension. Such files are easy to write from scratch
+ It automatically finds out runtime library dependencies, as well as
runtime dependencies on Perl and Python modules, and shell scripts
used durung post-install steps.
- It historically comes from RedHat and thus many people have
prejudice against it
- It has a lot of legacy features that were oriented to the old
versions of autoconf (see, for example, how the %makeinstall macro
expands--BTW RedHat doesn't use this macro)
- The user has to learn a bit beyond the basic bash syntax in order to
understand the existing spec files (i.e., know how various %{things}
expand)
- Some stock post-processing scripts contain small (i.e., ignorable)
bugs, bu
Re: BLFS-6.3 status
2008/3/5, Jeremy Henty <[EMAIL PROTECTED]>: > Dillo Classic certainly works well enough to be useful. Is that > enough? No, please go to http://www.lenta.ru/ (a Russian news site) and see wrong characters (if you don't apply the i18n patch). Ag decided that Links compiled without graphics is useless with such sites (even though in legacy non-UTF-8 locales it works--so Dillo is worse than Links), and the book must be self-consistent. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Package Management - technical comparisons
2008/3/5, Gerard Beekmans <[EMAIL PROTECTED]>: > If you feel you can talk about a potential PM candidate for LFS, please > write up a document that outlines the following: OK, deb--in my opinion, not a candidate at all. But let's have it just for comparison. > - it's strengths and weaknesses + well-tested in Debian and its derivatives, as well as in the OpenZaurus project - dpkg depends on itself in order to build successfully (workaround: before building dpkg, create a shell script called "dpkg" that prints the correct information when called with the "--print-architecture" flag, and place it into $PATH). - Due to this missed self-dependency and the recommendation to use the official Debian repository, the existing apt hint is broken beyond repair and has to be removed. The idea is that "nobody was able to make it work with LFS". - one has to build dpkg, debconf, debhelper, and all of their dependencies just to be able to build Debian packages with the canonical "debian/rules binary" command. If one wants to work with repositories, too, he has to install libapt and apt-get (or its alternative, aptitude). That's doable, but, IMHO, too much for Chapter 5. + It has all features that one expects from a working package manager, e.g., sane handling of the configuration files and dependency checking. If one installs the "ucf" package, it is even possible to merge the upstream changes into locally modified configuration files (of course, there is a chance to view the result during the installation and adjust it as needed). + It allows to build the package as non-root, and run only the actual package installation command (dpkg -i) as root. I.e., the correct permissions are stored in memory by the "fakeroot" command (that has to be installed from a separate package). * Debhelper allows some predefined steps to be taken (e.g., stripping, compression of man and info pages, but not catching obvious errors such as /usr/etc and UTF-8 encoded manual pages) on a per-package basis. To do so, explicit calls to debhelper must be placed in the debian/rules file. + It manipulates binary packages, with obvious benefits like the ability to deploy them, to revert to the old version quickly, and so on. + Apt allows creation of repositories, and aptitude remembers which binary packages are explicitly requested, and which are installed in order to satisfy dependencies. Unfortunately, there is no way to say "I installed libfoo-dev only to build and package bar and don't need it otherwise". - Packaging and build instructions are in multiple files in the "debian" directory. To write them, one has to know the Debian policy (i.e., how the official build daemon will call debian/rules), and how to call debhelper for various tasks such as finding shared library dependencies. Debian packaging scripts are verbose, not easy to write from scratch, and many people even inside Debian often use another already-debianized package as a template. + It automatically finds out runtime library dependencies, as well as runtime dependencies on Perl and Python modules, if told to do so by placing a call to "dh_shlibs", "dh_perl" and "dh_python" programs (from debhelper) into debian/rules (or use CDBS, see below). + It is buildsystem-independent, but one can take advantage of autoconf and other common buildsystems by installing the "cdbs" package or something similar. If CDBS is used, a debian/rules file for a CMMI package that also wants the --with-ipv6 option simplifies down to this: #!/usr/bin/make -f include /usr/share/cdbs/1/rules/debhelper.mk include /usr/share/cdbs/1/class/autotools.mk DEB_CONFIGURE_EXTRA_FLAGS := --with-ipv6 - (as one can see from the above example, there is no 1:1 correspondence between CDBS instructions and non-PM instructions, so they can't be autogenerated) - (as one can see from the example above, there is much more than one way to debianize a package, this will lead to disagreements what to choose) - The user has to learn a lot beyond the basic bash syntax in order to understand the existing debian/rules files (i.e., know all debhelper options). Worse, if some "debianization aid" such as "yada" is used (it plays a role similar to CDBS), and someone has to fix a bug in a package not maintained by him, discussions such as "yada expert is needed" are common on Debian mailing lists. + Text-based database > - why it's better than other candidates It isn't. > - why it's worse than other candidates See above. > - what it takes to integrate it in the LFS book As a minimum, install dpkg, debhelper, and all their dependencies. Write debian/rules files (they are just Makefiles) that install the package into DESTDIR, and call debhelper as needed. Optionally, write the list of installed files for each binary package into packagename.install files (the other alternative is to call dh_install or dh_move with the exlicit arguments what to move to a different package). List configuration files. > - what it likely is not ab
GnuPG-2.0.8
Hello all, I am currently working on getting a patch together for gnupg-2.0.8, to close out http://wiki.linuxfromscratch.org/blfs/ticket/2422 , and so we can clean up the dependency lists some, something Randy started back in August by adding most of the dependencies. Right now I'm running into a test failure that I haven't been able to work around (someone has reported this upstream, but no response yet. See https://bugs.g10code.com/gnupg/issue878 ). The failure is in test sm-sign+verify, and looks to be related to libksba. So far, I've tried updating to libksba-1.0.3, and applying patches from debian to libksba, and gnupg, but no luck. Also checked that this error also occurs in gnupg-2.0.7. Anyone else seeing this error? Or know how to fix it? -- Robert Daniels -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Format for the future LFS
On Wednesday 05 March 2008 07:52:19 Alexander E. Patrakov wrote: > [snip] > 3) How (from what form of sources) should all of this stuff be generated? One option then: There should be a variably verbose XML - based format describing everything from different languages for the end user (internationalization is a feature I do not see quite often raised here though), different package manager selection (if in the end you decide to support multiple versions, which is one thing to consider), package metadata information. As J. Greenlees suggested on this thread, it is advisable to have your own DTD, or a set of DTDs about this. Docbook will just _not_ cut it, and it was a *BAD* technical decision that leads the team here. I am not suggesting "bad" as non functional, but "bad" as in dead - end leading due to not having these options. There are also issues on not just the format of the DTD and its "layout" though, or the CSS/XHTML combinations for viewing things right; before touching them though, it is better to focus on XML itself and one simple thing: How verbose should it be, and should you "chain" it to the needs of a particular package manager? XML in general, suits the task because of its descriptive power, its almost immediate human - readability, its by default modular nature and its transfer - medium qualities even between different applications, in a standard and predictable by all editors manner. You could for example have different XML files describing alternative components to consider during the build of a particular "stream" of the book, done by different teams of people with talents that can group together nicely targeting a single sector of their choice. There can be quite diverse processing over these in order to produce the end "monolithic" XML/package from which everything else stems for that package; and you will also need to focus on the tools you want to have for something like this. It should be the XML document format to be the logical supergroup from which the eventual PM be "fed" the info from and not the other way around. Regardless of what you choose to do in the end, there are some extra issues: 1) the freedom you wish to have over the framework for the build cycle. 2) the choice you make on how to maintain the framework for automation. 3) how to prioritize different components so that this does not blow up on your face 4) accept the fact that in this way, you need something extremely accurate because increased variables in the game mean _increased_ eventual bugs that have nothing to do with the sum of the packages as distinct software entities over the project. 5) you need steady - rate development. Steady - rate. By the time you reach (5) there is also going to be a (10). But it will be at most 10. And everything should be easy to maintain. My only concern over this is that if you only wish to go around the pedantic route, then this is an overkill. If you don't, then it is a viable alternative with even bigger long term potential than what it seems right now. > -- > Alexander E. Patrakov George Makrydakis -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Poll about package management
Alexander E. Patrakov wrote: > Please reply to this message (please, limit this to the lfs-dev list > only) and mark with "X" the items that apply. If the answer is not the > same on your different Linux systems, write numbers of systems to > which each answer applies instead of a simple "X" mark. The resuts may > or may not be used for determining the future course of LFS. They will > certainly be used to verify or disprove my guess about the way the LFS > community is now split. > > [ ] I am an editor of LFS or one of the related projects > [X] I use LFS as my primary Linux system > [X] I use LFS on more than one PC (including virtual machines) > [ ] I deviate a lot from LFS (not counting package updates as deviations) > [X] I deviate a lot from BLFS (not counting package updates as deviations) > > I use the following package management technique: > ( ) It's all in my head! > ( ) I trust the lists of files in the book > ( ) I rebuild everything every three months or less, so there is no > need to manage anything! > ( ) Installation script tracing with installwatch or checkinstall > ( ) Installation script tracing with some other tool > ( ) Timestamp-based "find" operation > (X) User-based > ( ) RPM > ( ) DPKG > ( ) Simple binary tarballs produced with DESTDIR > ( ) Other DESTDIR-based method of producing binary packages > ( ) Other > > I use the following features provided by a package manager: > [ ] Knowing where each file comes from > [ ] Clean uninstallation of a package > [ ] Removal of obsolete files when upgrading to a new version > [ ] Ability to upgrade toolchain components (most notably, glibc) painlessly > [ ] Ability to revert mistakes easily and quickly by installing an old > binary package > [ ] Ability to compile once, deploy on many macines > [ ] Scripting the build > > I will ignore the future LFS advice on package management if it > [ ] Can't be applied on a busy machine where many files are > accessed/modified everyy minute > [ ] Can't be used to transfer packages to another machine > [ ] Interferes with config.site files described in DIY-linux > [ ] Will clobber configuration files wen upgrading package versions > [ ] Doesn't explain how to package software beyond BLFS > [ ] Requires learning another language/syntax besides bash shell syntax > [ ] Exists at all > > My input on this. regs, peram -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Poll is closed
I wrote: > Please reply to this message (please, limit this to the lfs-dev list > only) and mark with "X" the items that apply. Any replies after this will be ignored. Thanks for your input. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Format for the future LFS
Alexander E. Patrakov wrote: > > Unfortunately, the current DocBook toolchain is meant to produce a > single book with instructions that are meant for copying and pasting. > It is not suitable for generating both the non-PM-aware instructions > and spec files from the same source, and is not able to modify the > surrounding text accordingly. Worse, we don't even have a mockup HTML > of how this should look like! > As Gerard suggested, the instructions should not be considered relevant to the content displayed. "Who, What, Why, When and Where". "How" can be discovered by just viewing the (chosen PM) spec and invocation script as they are, plain text. Whether the chosen spec is RPM, DESTDIR or NONE should ideally affect only the "Where" text. In other words the text could be a simple "toXML markup". Script and PM selection are where the problems are. All supported PM's in all Packages/Modules: That is a great endeavor. That's my take. David Jensen -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Package Management - technical comparisons
> I really do disagree with this stance. As an educative, as well as > practical project, we should show at least one worked example. Just > like we do with SysVInit and the bootscripts (which several of us > don't ever use any more). No one has to use the example, but the > example itself shows that: My 4th paragraph started with: "Having said that, we will probably get to a scenario where we need to settle on something we will be using ourselves for the LFS project." That would cover the argument you brought up. I fully anticipate that happening (whether we like it or not). Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Package Management - technical comparisons
Gerard Beekmans wrote: > The more we discuss it, the more PM becomes a focal point. > > We need a clearly defined list of pros, cons and technical explanations > plus their limitations of each viable choice - all the information that > a user needs to make an informed decision while keeping in mind that > some of these programs may never have been used (or heard of) before. So > we can't assume a basic working understanding of the programs. > Though i have yet to use it myself, i'd be interested in reading such a review of *Paludis*, at least for comparative purposes. http://paludis.pioto.org/ One feature particularly caught my eye:- "Support for repositories containing things other than ebuilds". I've been unable thus far to determine the precise extent of that support, but it seems to suggest that the PM could be androgenous, & therefore well-suited to a user-base with diverse prior experience of other PM's & their various spec-file flavours. It also appears to support & indeed endorse the running of test-suites, something i'm unqualified to comment on with regard to other PM's. Based on this article:- http://lab.obsethryl.eu/content/paludis-gentoo-and-ciaran-mccreesh-uncensored ...I believe George Makrydakis may be well-equipped to provide such a review, but i'd appreciate it wherever it came from. If this request is deemed inappropriate &/or naive, no offense will be taken from being told so. ;) > - it's strengths and weaknesses > - why it's better than other candidates > - why it's worse than other candidates > - what it takes to integrate it in the LFS book >* not looking for installation instructions. Just explain the impact > and changes that will be required for successful use > - what it likely is not able to do for its users > - how well it can deal with matters such as conflict resolution and > dependency handling > -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Format for the future LFS
>> This idea didn't come to fruition mostly due to server resource >> limitations. That problem shouldn't exist anymore nowadays. > > Here I am not sure whether I agree about the reason, but this > disagreement is off-topic for this thread. It truly was the primary reason. The LFS server back then did not have enough CPU speed or RAM to handle dynamic requests like that. It took about 30 minutes to render one static LFS book back in those days. Imagine hundreds of requests a day. It wasn't going to work from a purely physical point of view. The idea had died with that realization. > I want the idea to be clarified by providing samples how the generated > content should look like, in terms of HTML layout. Such samples would > help us classify the replaceable/optional items and thus avoid > redesigning the generator more times than it is needed. We don't need to worry about the physical presentation of the material yet. It's the lesser of concerns. One possible way is that based on user selection on the website it creates a custom index.xml file which pulls in different chapter 5/6 XML files that make up the individual installation pages. That would be one way to get a custom book. The real issue at hand is how we can save ourselves a lot of time seeing we'll have regular package installations (what we currently have in the book) and the RPM/DEB/DESTDIR/etc versions. If a package changes we don't want to rewrite too many files and make the same changes. Is that (partly) what you were saying? There are many questions still and we've started to run ahead of ourselves and trying to tackle too many things at once. I'm going to be collecting Package Manager tech explanations first. It may not be the best place to start in the end, but it's a place and we need to move forward and not endlessly discuss where the best place to start is. That will all fall into place soon enough. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Poll results
First, thanks to all the participants for the input. For the purpose of processing the data, any "~" was interpreted as "no" (except for David Jensen's "[~] I am an editor" answer), and some vote marks were corrected if they contradict the words placed near them. E.g., Vladimir A. Pavlov didn't place a mark near the "I will ignore the future LFS advice on package management if it Can't be applied on a busy machine where many files are accessed/modified every minute" item, but did say "I will definitely ignore any package manager using "find" to create a package file list", so I counted his vote as though it had the mark. So, here are the results. They indicate the current state of the project and should in no way influence its progress directly. First, a lot of options were just red herrings (e.g., almost the whole "I use the following features" section) to mask my intentions. You are free to interpret them as you wish, though. Second, the part about the currently used package management technique almost failed, because many people answered about their non-LFS systems, or more than once without indicating the number of machines to which each option applies. For analysis, correlation coefficients were calculated between each pair of available options, except those to which people answer too similarly, e.g. "I use dpkg" (in this case the correlation coefficients are badly defined). Below, correlation coefficients with a checkbox are not shown if 3 or less people have this checkbox unchecked, or 3 or less people have this checkbox checked. Correlation coefficients with the absolute value above 0.3 (arbitrary unscientific number chosen just to limit the output) are listed below. Some of them are obvious, some aren't. Correlation coefficients of any checkbox with itself (1.00 by definition) and of roundboxes in the "I use this kind of PM" area between each other are not shown. 0.65: "I use the clean-uninstallation feature"/"I use PM for removal of obsolete files" 0.53: "I use PM for removal of obsolete files"/"I use PM to revert mistakes" 0.53: "I use PM to revert mistakes"/"I won't use PM that clobbers config files" 0.51: "I want to know where each file comes from"/"I use PM for removal of obsolete files" 0.50: "I use the clean-uninstallation feature"/"I use PM to revert mistakes" 0.49: "I use the scripting feature of PM"/"I won't use PM that clobbers config files" 0.48: "I trust the book"/"I will ignore PM that fails on busy system" 0.45: "I will ignore PM that doesn't allow package transfer"/"I won't use PM that clobbers config files" 0.44: "I use PM to compile once, deploy everywhere"/"I will ignore PM that doesn't allow package transfer" 0.43: "I use the scripting feature of PM"/"I will ignore PM that doesn't allow package transfer" 0.43: "I deviate from LFS"/"I use simple DESTDIR-based binary packages" 0.43: "I want to know where each file comes from"/"I use the clean-uninstallation feature" 0.41: "I am an editor"/"I use the scripting feature of PM" -0.41: "I use PM for removal of obsolete files"/"I will ignore any instructions on PM" 0.41: "I use PM to revert mistakes"/"I use the scripting feature of PM" -0.41: "I won't use PM that clobbers config files"/"I will ignore any instructions on PM" -0.40: "I rebuild often"/"I want to know where each file comes from" 0.39: "I am an editor"/"I use timestamp+find-based PM" 0.39: "I rebuild often"/"I will ignore PM that fails on busy system" 0.39: "I use simple binary packages"/"I use PM to revert mistakes" 0.39: "I use simple binary packages"/"I will ignore PM that fails on busy system" 0.38: "I deviate from LFS"/"I use PM to compile once, deploy everywhere" -0.37: "I use LFS on >1 PC"/"I use PM for removal of obsolete files" -0.36: "User-based PM"/"I use PM to revert mistakes" -0.35: "User-based PM"/"I won't use PM that clobbers config files" 0.35: "I am an editor"/"I want to know where each file comes from" 0.35: "I am an editor"/"I use the clean-uninstallation feature" -0.34: "I use LFS on >1 PC"/"I use the clean-uninstallation feature" 0.34: "I deviate from LFS"/"I deviate from BLFS" 0.34: "I deviate from LFS"/"I use the scripting feature of PM" -0.33: I use LFS as primary system"/"I will ignore PM that doesn't allow package transfer" 0.33: "I use PM to revert mistakes"/"I will ignore PM that fails on busy system" 0.32: "I use PM for upgrading toolchain easily"/"I use PM to compile once, deploy everywhere" 0.32: "I will ignore PM that fails on busy system"/"I will ignore PM with non-bash syntax" -0.31: "I trust the book"/"I want to know where each file comes from" -0.31: "I trust the book"/"I use the clean-uninstallation feature" 0.31: "I use PM for removal of obsolete files"/"I won't use PM that clobbers config files" Now the important, in my opinion, parts: DESTDIR-based techniques are not as popular as others! So we have to learn them first before writing about them. Probably, this happens because the current
Re: Poll about package management
On Tue, Mar 4, 2008 at 9:16 PM, Alexander E. Patrakov <[EMAIL PROTECTED]> wrote: > > Still, please provide them. With only 8 editors who answered the poll, > the correlation coefficients involving the "I am an editor" checkbox > have an expected relative error of 35%, and you can bring this down to > 33% (just a joke - the error of estimating the error is of course > larger than those 2%). What package management requirements the book uses aren't really that important to me, which is why I didn't answer. I'd much rather just follow what the community wants. But, if you're interested in what I consider important from a package manager, you can probably put an X in every box. After messing around with my own package manager and finding out all the limitations, I realized I really do want all those features provided by the big guys, even at the sacrifice of some automation. I personally lean towards RPM because I'm most familiar with Fedora and I conceptually like the idea of keeping all the information in a single file, unlike dpkg where you have a splattering of files. But I wouldn't be opposed to any package manager that people want to use, no matter how simplistic. I'm always free to do what I want to do. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Package Management - technical comparisons
On Wed, Mar 5, 2008 at 1:35 AM, Alexander E. Patrakov
<[EMAIL PROTECTED]> wrote:
> - It has a lot of legacy features that were oriented to the old
> versions of autoconf (see, for example, how the %makeinstall macro
> expands--BTW RedHat doesn't use this macro)
Nobody uses this anymore, but it can be useful in the case of a
Makefile with hardcoded directories.
http://gitweb.dwcab.com/?p=pound.git;a=blob;f=jpeg/jpeg.spec;hb=HEAD
> - The %configure macro interferes (ore, more correctly, duplicates or
> overlaps in functionality) with config.site files, but the
> autogenerated spec files are not expected to use this macro, so this
> is likely to be a non-issue. However, in this case, setting the
> default CFLAGS from RPM macros, as documented, will stop working.
I don't consider this a bad thing since your rpm macros essentially
deprecate config.site. echo '%_prefix /usr/local' >> ~/.rpmmacros.
Also, you can easily write your own %configure replacement if you
prefer config.site:
cat > /etc/rpm/macros.lfs << "EOF"
%configure \
export CFLAGS="${CFLAGS:-%optflags}"; \
export CXXFLAGS="${CXXFLAGS:-%optflags}; \
export CONFIG_SITE=/path/to/config.site; \
./configure
EOF
I'm pretty sure that Mandriva and SUSE override the default
%configure. I'm personally considering overriding it so that I can
specify the shell to call configure with since a lot of them have
bashisms.
I don't want to hijack this thread into a merits of RPM thread, but
just wanted to comment on those two points.
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Package Management - technical comparisons
On Wed, 05 Mar 2008 09:54:37 -0700 Gerard Beekmans <[EMAIL PROTECTED]> wrote: > > I really do disagree with this stance. As an educative, as well as > > practical project, we should show at least one worked example. Just > > like we do with SysVInit and the bootscripts (which several of us > > don't ever use any more). No one has to use the example, but the > > example itself shows that: > > My 4th paragraph started with: "Having said that, we will probably get > to a scenario where we need to settle on something we will be using > ourselves for the LFS project." > > That would cover the argument you brought up. I fully anticipate that > happening (whether we like it or not). > > Gerard OK, I read that as part of the LFS infrastructure, not part of the build per se. Thanks for the clarification. R. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Poll results
On Wednesday 05 March 2008 20:21, Alexander E. Patrakov wrote: > > ... > > Now the important, in my opinion, parts: > > DESTDIR-based techniques are not as popular as others! Why you made such conclusion from this poll? > ... > The "I rebuild often" and "I use the scripting feature of the PM" checkboxes > are > not correlated (-0.06). I find this strange and cannot explain. IMO 'building' and 'packaging' are different activities. If PM has own opinion, how to build software X, this is problem as for package maintainers, as for software developers. > ... > > It is surprising that a lot of users (among both editors and non-editors) > will > accept a totally broken package manager that overwrites their customizations > of > the configuration files. This indicates that they probably didn't try to > implement package management themselves (or didn't even package stuff for > regular distributions) and thus didn't meet the problem. Existence of such > users > that can't tell a key property of a good PM will surelly negatively affect > the > quality of the resulting pages in LFS. Not agree: looks like many people consider _all_ existing PMs as 'not suitable'. Some tasks, that associated with PM in this poll, really refer to other classes of software---like Sun's BigAdmin (maintaining high-availability services, configuration management) or Perforce (configuration management). >From my everyday practice, PM only extra headache, not help: - produce identical software on a few hosts (with different life cycle of this hosts); - produce identical (but, may be a bit different) configuration of software on a few hosts; - update software, that underlie under some service (sometimes a lot of packages) with predictable, controllable results and minimum service down time; rollback very useful here; - even package dependency is a problem too: I hate Debian's approach since upgrading Perl's revision led to upgrade mail subsystem, package management subsystem, init scripts, database, host configuration, ... Thanks a lot for this experience! > I.e., again, we have to learn more about > package management before attempting to write about it. > > -- > Alexander E. Patrakov -- - ptr -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Poll results
Interesting results, I'm glad you did this Alexander. It's very interesting to see how what everyone thinks is important balanced against one another. On Wed, Mar 5, 2008 at 12:21 PM, Alexander E. Patrakov <[EMAIL PROTECTED]> wrote: > The "I rebuild often" and "I use the scripting feature of the PM" checkboxes > are > not correlated (-0.06). I find this strange and cannot explain. Scripting is pretty useful even if you only plan to build once. I personally rebuild as little as possible, being only when something breaks. But being able to fall back on your exact options (through the book or through a customized script) months later is borderline essential for myself. My brains don't like it when I try to remember things like precise build instructions for some obscure package. Scripting can be useful with or without the 'often'. But sometimes a rebuild might be something that you whip up out of the blue. In my opinion the independence of these two variables makes sense. Having scripting for frequent rebuilds seems like a bonus. > 0.53: "I use PM to revert mistakes"/"I won't use PM that clobbers config > files" I think I feel the strongest towards this statistic. It's at these times that I either loved or hated package management in the past. Jonathan 50% of the time statistics are accurate 100% of the time -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Poll results
Alexander E. Patrakov wrote: I.e., again, we have to learn more about > package management before attempting to write about it. > exactly why I didn't vote, I don't know enough to have any meaningful input :) Jaqui -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Poll results
On Wed, Mar 05, 2008 at 10:21:27PM +0500, Alexander E. Patrakov wrote: > > Now the important, in my opinion, parts: > > DESTDIR-based techniques are not as popular as others! So we have to learn > them > first before writing about them. Probably, this happens because the current > LFS > book is not really suited to DESTDIR. See also the high correlation > coefficient > (0.43) between this and deviation from LFS. > > The "I rebuild often" and "I use the scripting feature of the PM" checkboxes > are > not correlated (-0.06). I find this strange and cannot explain. > Speaking, as always, only for myself - I use the scripting feature of my scripts! No, that doesn't sound like English, my point is that any need for pm came late to the party - first build LFS, then decide that I wanted to keep building it, and only later decide to use 'find' for minimal pm. Summary: in my opinion, I use the pm feature of my scripts - putting it the other way is cart-before-horse. As a 'find' user, I fully accept that DESTDIR has its place - e.g. looking at a version upgrade - but it isn't part of my normal pm. > The deviation rates from both LFS and BLFS are not correlated to the editor > status. Thus, we can say that the community is not split. > > It is surprising that a lot of users (among both editors and non-editors) > will > accept a totally broken package manager that overwrites their customizations > of > the configuration files. This indicates that they probably didn't try to > implement package management themselves (or didn't even package stuff for > regular distributions) and thus didn't meet the problem. Existence of such > users > that can't tell a key property of a good PM will surelly negatively affect > the > quality of the resulting pages in LFS. I.e., again, we have to learn more > about > package management before attempting to write about it. > Here, I think you are reading too much into the results - you knew what you were looking to find out, but people interpreted your questions differently. In practice, I find it hard to believe _any_ LFS users would willingly accept a pm that overwrites their customizations or configurations - we're the anal guys who want to deal with the nuts and bolts, even if sometimes that means we reinvent the wheel. (Did I really say that?) Of course, if I was supporting users or public-facing servers I'd probably choose to go along with a preferred distro's pm and just accept that it would overwrite my preferences until I'd spent years learning to tame it. Actually, I'll qualify that slightly - as soon as you move outside LFS, at least on non-x86, you discover package maintainers don't always do what we now regard as the normal way of doing things. I have to be aware that anytime I want to change the result, it might blow up in my face - e.g in dhcp-3.0.5 try ./configure --disable-static : why would I expect some weird pm to be any different, it's just another hurdle to get past ? ĸen -- OK, you're so clever, you tell us what colour this wheel should be. [THHGTTG] -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Poll about package management
Alexander E. Patrakov wrote: > 2008/3/4, Greg Schafer <[EMAIL PROTECTED]>: >> [x] file conflict detection <-- essential feature >> [x] simple BLFS style dependencies <-- essential feature >> [x] pre/post install scripts <-- essential feature >> [x] ability to build the whole distro as non-root <-- killer feature >> [x] "meta" package support (package groups) >> [x] knowledge of which packages are pulled in as dependencies and which >> are installed explicitly >> >> BTW, Pacman does all of the above. > > Yes, it does. I have a virtual machine with Arch, and its package > manager really looks good. I have not tried to write my own build > script for it yet, though. Since you know more about Pacman: does it > allow running arbitrary scripts on the DESTDIR contents before > actually creating a package? Um, I don't think so. However, while Pacman itself is written in C, the "makepkg" portion of the system is a Bash script which allows easy hackability. That's what allowed Alex Merry to write the fake_install() patch that I still use today. While I'm a Pacman fan, it is by no means a perfect PM. It uses an ASCII text package database which tends to slow down when you have a zillion packages installed. It probably won't do everything you want, like easy splitting off of -devel and runtime packages. The config file handling is allegedly based on the same algos as RPM. Having said all that, I'm still on 2.9.x. A Refbuild reader contacted me recently and said he was running the latest version successfully so I'll look at upgrading once I finish beating on GCC-4.3 and various toolchain/build method matters. You seem to be striving for perfection. When I want all the bells and whistles I run a mainstream distro. It is simply too labour intensive to have "the lot" on a self built system. I looked at the amount of effort Dan has apparently put into his RPM based system and weeped :-( Pacman is good enough for my meagre needs, but I wouldn't use it if, for example, I was trying to be the next Ubuntu. Regards Greg -- http://www.diy-linux.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Poll about package management
On Wed, Mar 5, 2008 at 4:35 PM, Greg Schafer <[EMAIL PROTECTED]> wrote: > > You seem to be striving for perfection. When I want all the bells and > whistles I run a mainstream distro. It is simply too labour intensive to > have "the lot" on a self built system. I looked at the amount of effort > Dan has apparently put into his RPM based system and weeped :-( :) I was telling Jeremy that when I started converting all my specs to RPM, I figured it'd take a month or two just hammering through the conversion. That started in October and has seemingly no end in sight. But now that I've gotten this far, you can be damn sure that I'll at least enjoy my one click[1] installs for a few months before I abandon ship. Looking back, I probably should have just loaded up Fedora, but I just can't do it. I like having things under my control a little too much. -- Dan [1] http://packagekit.org/pk-screenshots.html -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: The creation of "lfs" user and its possible security issues
On Monday March 3 2008 07:47:16 am mundoalem wrote: > Hello everyone! > > As I was reading for the first time the Linux From Scratch > books version 6.3 this weekend, I noticed that section: > > "4.3. Adding the LFS User" > http://www.linuxfromscratch.org/lfs/view/stable/chapter04/addinguser.html > > is lacking of notes on security issues about the creation > of the "lfs" user and "lfs" group. I know the book just can't > cover every aspect of security problems and errors it might > occur if you do the things the book tells you to do. > The sysadm should know what he is typing. A weak password on the lfs account could lead to both local and remote unauthorized use, which in turn could lead to a trojan-horsed coreutils patch, which leads to a privilege escalation from /tools when root runs the coreutils test suite, and then a root backdoor. It could happen. robert pgpDkcJKxqoEr.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: The creation of "lfs" user and its possible security issues
Robert Connolly wrote: > On Monday March 3 2008 07:47:16 am mundoalem wrote: >> Hello everyone! >> >> As I was reading for the first time the Linux From Scratch >> books version 6.3 this weekend, I noticed that section: >> >> "4.3. Adding the LFS User" >> http://www.linuxfromscratch.org/lfs/view/stable/chapter04/addinguser.html >> >> is lacking of notes on security issues about the creation >> of the "lfs" user and "lfs" group. I know the book just can't >> cover every aspect of security problems and errors it might >> occur if you do the things the book tells you to do. >> The sysadm should know what he is typing. > > A weak password on the lfs account could lead to both local and remote > unauthorized use, which in turn could lead to a trojan-horsed coreutils > patch, which leads to a privilege escalation from /tools when root runs the > coreutils test suite, and then a root backdoor. > > It could happen. IMO, only if there are untrusted users on the system or sshd is misconfigured with PermitEmptyPasswords. We can't cover *every* possibility. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Poll about package management
Dan Nicholson wrote these words on 03/05/08 11:22 CST: > What package management requirements the book uses aren't really that > important to me, which is why I didn't answer. I'd much rather just > follow what the community wants. What Dan said. (as an explanation why I didn't answer as well) I'll continue to do it 'my way'. And that may end up being a really bad thing (for me) if LFS goes the direction where a PM is required. I would have to probably keep my own methods and attempt to update packages using my methods, but try to fudge something that fits the book. So it be known, I'm against PM as something implemented by LFS. There's just too many deviations and alternative choices. Richard's analogy of SysVinit and bootscripts is not the same. There aren't that many init methods, though there is tons of PMs. You cannot compare the two. -- Randy rmlscsi: [bogomips 1003.22] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 19:57:01 up 17 days, 11:42, 1 user, load average: 0.12, 0.20, 0.16 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: The creation of "lfs" user and its possible security issues
Bruce Dubbs wrote these words on 03/05/08 19:51 CST: > We can't cover *every* possibility. That is so true. However, HLFS should be the fall back that covers *every* possibility. A mention of the LFS user being created on the host machine using a strong password probably wouldn't hurt. -- Randy rmlscsi: [bogomips 1003.22] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 20:04:01 up 17 days, 11:49, 1 user, load average: 1.48, 0.84, 0.43 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Poll about package management
Greg Schafer wrote: > Alexander E. Patrakov wrote: >> does it >> allow running arbitrary scripts on the DESTDIR contents before >> actually creating a package? > > Um, I don't think so. However, while Pacman itself is written in C, the > "makepkg" portion of the system is a Bash script which allows easy > hackability. That's what allowed Alex Merry to write the fake_install() > patch that I still use today. I.e., writing such patch would be easy. That's enough. > While I'm a Pacman fan, it is by no means a perfect PM. It uses an > ASCII text package database which tends to slow down when you have a > zillion packages installed. The same applies to dpkg. > It probably won't do everything you want, like > easy splitting off of -devel and runtime packages. How does Arch Linux handle library transitions then? E.g., suppose that a new version of OpenSSL appear that builds libssl.so.0.9.9. How do they avoid the situation that some of the binary packages (those not yet rebuilt) want the old libssl library? > You seem to be striving for perfection. When I want all the bells and > whistles I run a mainstream distro. Without this, LFS is unsuitable for production use. Nevertheless, people want it. There are only two ways to deal with this situation: make LFS work perfectly, or drive them away from LFS even before they think about it in production. So, we are back at the old dilemma about LFS-course (that has to be simple and fully understandable by everyone, possibly even oversimplified, and it is not a bug that it doesn't work for a significant portion of users) vs LFS-distro (that also has to be present, just to show the shortcomings of LFS-course as a distro). > It is simply too labour intensive to > have "the lot" on a self built system. I looked at the amount of effort > Dan has apparently put into his RPM based system and weeped :-( Pacman is > good enough for my meagre needs, but I wouldn't use it if, for example, I > was trying to be the next Ubuntu. Here I fully agree. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Poll about package management
Alexander E. Patrakov wrote: > Greg Schafer wrote: >> You seem to be striving for perfection. When I want all the bells and >> whistles I run a mainstream distro. > > Without this, LFS is unsuitable for production use. Expletive! I use LFS all the time for production use without PM. Alex, label your opinions as your opinions and not absolutes. For *you*, LFS is unsuitable for production use. Not everyone. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Poll about package management
I wrote: > Greg Schafer wrote: >> You seem to be striving for perfection. When I want all the bells and >> whistles I run a mainstream distro. > > Without this, LFS is unsuitable for production use. Nevertheless, people > want it. There are only two ways to deal with this situation: make LFS > work perfectly, or drive them away from LFS even before they think about > it in production. So, we are back at the old dilemma about LFS-course > (that has to be simple and fully understandable by everyone, possibly > even oversimplified, and it is not a bug that it doesn't work for a > significant portion of users) vs LFS-distro (that also has to be > present, just to show the shortcomings of LFS-course as a distro). Sorry for this part of the message, it's too flame-prone. Here is a better expression of the same thought: Some people do want to use LFS in production. There are only two ways to deal with this situation: make LFS work perfectly, or drive them away from LFS, e.g., by including somewhere in the preface some concrete missing features that make LFS unsuitable for production use, and give some foundations to the fact that these features are really required. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Poll about package management
Alexander E. Patrakov wrote: > Some people do want to use LFS in production. There are only two ways to deal > with this situation: make LFS work perfectly, or drive them away from LFS, > e.g., > by including somewhere in the preface some concrete missing features that > make > LFS unsuitable for production use, and give some foundations to the fact that > these features are really required. We still disagree with the concept of "make LFS work perfectly". It does for me and for the LFS project. The two servers, quantum and anduin get a *lot* of traffic. They are certainly "in production". They also work fine: [EMAIL PROTECTED] ~]$ w 23:18:44 up 281 days [EMAIL PROTECTED] ~ ]$ w 22:18:26 up 157 days AFAIK, the only time they have ever been down is when there have been hardware problems. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Poll about package management
Alexander E. Patrakov wrote: > Some people do want to use LFS in production. There are only two ways to deal > with this situation: make LFS work perfectly, or drive them away from LFS, > e.g., > by including somewhere in the preface some concrete missing features that > make > LFS unsuitable for production use, and give some foundations to the fact that > these features are really required. I understand your motive Alex, but I think the inherent problem with this stance is that 'unsuitable for production use' is a relative term. For some environments, all that is required for a Linux system to be suitable for a particular production use is that it handles whatever tasks it has been assigned reliably and consistently. In one small office that I provided service for, they needed a reliable network file server with no other real needs - essentially a drop box for multiple people. That equated to LFS with a minimal Samba configuration. That machine has had an uptime of over a year and it gets used daily. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
hal nitpick
Was just trying this package out, and I noticed it appeared to have more runtime optional dependencies then were listed on the page. hal-device-manager wants pygtk (which wanted pygobject). -- Nathan Coulson (conathan) -- nathan at linuxfromscratch org conathan at gmail com -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Poll about package management
Alexander E. Patrakov wrote: > Greg Schafer wrote: >> Alexander E. Patrakov wrote: >>> does it >>> allow running arbitrary scripts on the DESTDIR contents before >>> actually creating a package? >> Um, I don't think so. However, while Pacman itself is written in C, the >> "makepkg" portion of the system is a Bash script which allows easy >> hackability. That's what allowed Alex Merry to write the fake_install() >> patch that I still use today. > > I.e., writing such patch would be easy. That's enough. There is a good perl based start to handling the differences in package manager formats. http://kitenet.net/~joey/code/alien/ It's often included as an option in the debian and rpm distros, to increase the ease of finding packages in a package manager format. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
