.
-
butchydave
- Posts: 44
- Joined: Sat 03 Mar 2012, 14:50
Puppies..
Personally as a user only knowing enough to get what I want from the forum etc.. I AM THRILLED to death that Barry and others offer me for FREE their skills and time. They must love Puppy a lot to donate time and resources. Yes, it's not perfect, but neither is MS with BILLIONS of $$$!! I read the forums often and pick up bits and pieces that make me more proficient as a user. Almost never do I see a RTFM from the people that know what the heck they are doing. I lost count long ago of the number of Pups available. I usually just use pets, not the PPM. I wish to thank Barry and all the rest of you for many pleasurable hours of exploring and learning Linux! That does also include you and your OS which I have tried and liked. Everyone, including users like me thank you-thank you!!
-
BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
Maybe you are describing iguleder's roar-ng, which is fork of Puppy that compiles everything from source.simargl wrote:When you get PET package you can't tell is it for x86 or 64 bits CPU, how is it compiled, what patches are used. Now, if something like those build scripts could be included in Puppy (replace pet.specs), it wouldn't just eliminate those problems, but also make packages maintaining and upgrading much easier. Puppy could have its own GCC compiler, perfect home grown toolchain and stop relying on other tools (like T2), eliminate current library mismatches with too many different base versions and become really independent distribution of it own.
https://github.com/iguleder/roar-ng-ii
http://www.murga-linux.com/puppy/viewtopic.php?t=75753
[url]https://bkhome.org/news/[/url]
-
darry1966
Re: T2, Buildroot, ... next Wary
simargl wrote:http://bkhome.org/blog2/?viewDetailed=00307
http://bkhome.org/blog2/?viewDetailed=00306
Can someone explain how do you see this: Is Puppy based on Ubuntu, once announced as
next official Puppy Wary (some sort of LTS) still regarded as good idea, or compiling everything from
scratch is now chosen path to follow. Is more fragmenting in Puppy's ecosystem really needed,
does it bring any benefit to typical user. After all, abiword is abiword whether you choose to
spend time compiling it, or someone else (other disto packager) does it for you.
Main problem for Puppy, as I see it, is package manager that is currently not fast and reliable
enough. It should work at least 99% of time, asking users to click "examine dependencies"
should be removed, same as "choose mirror"; those things should be automatic. I think simple
and best solution is just switch to Synaptic package manager, and make Puppy perfectly
compatible with apt-get. Debian packagers already split DEBs from devel files, so what do
you think: Is that kind of Puppy system really hard to make.
I think Barry is getting back to his roots or Puppie's roots talking about small systems instead of bloat just like puppy used to be.
Sounds like he is getting inspired good on him. Personally I think it is better than the precise is the new Wary idea.
Anyway Barry best of luck and go with it.
src2pkg can be used to create uniform *.pet packages, but you are right in thinking that the package format itself is deficient. In order to achieve build-repeatability, proper installation and/or upgrade/downgrade capability and other important features, one must take into account the package creation software and method, the software and method for installation , etc., and the format of the package, vis-a-vis payload, installation scripts or other database items -like dependency information which can only be acurately generated at package compile/build time.
The *.pet (and old *.pup) package formats and tools are simply too simple, as compared to any other package type.
src2pkg itself can create packages of several formats, including the '*.tpkg' format which I designed -it's quite similar to the Arch system. src2pkg can do all sorts of neat things while creating packages -like splitting the packages, compressing things, optimizing the compile options, etc. The build scripts, if used, work on multiple arches without changes. src2pkg can even build many packages without any build script or extra command-line options, but for repeatability, all package-builds should include a build script, description file and any extra items needed to complete the package, like init or pre/post-install/remove scripts. src2pkg builds a quite complete set of database files when build *.tpkg packages.
The *.pet (and old *.pup) package formats and tools are simply too simple, as compared to any other package type.
src2pkg itself can create packages of several formats, including the '*.tpkg' format which I designed -it's quite similar to the Arch system. src2pkg can do all sorts of neat things while creating packages -like splitting the packages, compressing things, optimizing the compile options, etc. The build scripts, if used, work on multiple arches without changes. src2pkg can even build many packages without any build script or extra command-line options, but for repeatability, all package-builds should include a build script, description file and any extra items needed to complete the package, like init or pre/post-install/remove scripts. src2pkg builds a quite complete set of database files when build *.tpkg packages.
Sorry, but it would take much longer than a couple of days to write a package manager. The problem really starts with the package format itself -it has to be able to incorporate the features you mention. Then, a package manager must be written which implements that side of the problem -installing, upgrading, removal. downgrade, etc. Then, the last thing which most people would think of, the software to create such packages. Actually, all three have to be taken into account together. If the package format makes it hard or slow to be realized by the package manager, then the format needs to be changed. The build scripts or software for creating packages is actually the most important as it gives the best chance for efficiently using the developers time. OF course, a build script can be completely self-standing like slackware scripts are, or can be part of a program or scripts which use build scripts which are more like conf files -like the arch system.
Dependency information and resolution are the hardest thing to implement -and to think out as concepts. The info has to be generated at package build-time. Presenting and/or using that info must be done in the package manager. The format must contain enough database parts to be able to transmit info to the package installer/manager to deal with any actions which need to be taken before or after installing or removing a package, and enough info about the dependencies so that they can be handled.
Since I have actually done this -create a package format, software which manages the installation, etc. and software which creates such packages, I know a little about what has to be considered. You might think that it would be easiest to simply use an already-existing package format -but hopefully creating all the packages especially for your distro. However, this approach has some of the same drawbacks as basing y distro partially or wholly on packages which come from another distro -you'll usually wind up with some deficiency as you percieve things.
On the other hand, if you are gonna do the whole thing, you can adjust things as needed. I started with a package format much like the slackware packages, but with extra database files. Then, I discovered that there were certain Slackware package which cause a dependency nightmare -simply because of what is included in them, or the way they are named. For my format, I was able to eliminate such problems easily, since I didn't need to ask anyone to change the package content, or try to create work-arounds which would deal with the symptoms without fixing the problems.
I insist that a working system can not be easily or quickly created -if for no other reason than this: packaging and installing software can't be done using a simple, single method -there are loads of packages which require packaging/installation steps which are quite out of the ordinary.
If working from scratch, you need to start with what you think might work, and then create and install packages -*lots* and *lots* of packages till you run into problems which force you to re-think, re-write and then re-create and re-install all those packages again using the 'new' package format. of course, anyone with lots of experience with these subjects has an advantage.
It is really interesting -and worth the effort in my case.
Since Puppy can run live, installed or semi-installed it presents some unusual problems which must be dealt with -but these needs explain exactly why someone elses' package format and packaging software may not be adequate.
Even without an adequate package format or with none at all like LFS, build scripts can and should be used. I find it insane to spend hours/days creating a package and not having a script which will exactyl repeat the steps. The lack of real build scripts makes the devs/maintainers job infinitley harder and slower.
Dependency information and resolution are the hardest thing to implement -and to think out as concepts. The info has to be generated at package build-time. Presenting and/or using that info must be done in the package manager. The format must contain enough database parts to be able to transmit info to the package installer/manager to deal with any actions which need to be taken before or after installing or removing a package, and enough info about the dependencies so that they can be handled.
Since I have actually done this -create a package format, software which manages the installation, etc. and software which creates such packages, I know a little about what has to be considered. You might think that it would be easiest to simply use an already-existing package format -but hopefully creating all the packages especially for your distro. However, this approach has some of the same drawbacks as basing y distro partially or wholly on packages which come from another distro -you'll usually wind up with some deficiency as you percieve things.
On the other hand, if you are gonna do the whole thing, you can adjust things as needed. I started with a package format much like the slackware packages, but with extra database files. Then, I discovered that there were certain Slackware package which cause a dependency nightmare -simply because of what is included in them, or the way they are named. For my format, I was able to eliminate such problems easily, since I didn't need to ask anyone to change the package content, or try to create work-arounds which would deal with the symptoms without fixing the problems.
I insist that a working system can not be easily or quickly created -if for no other reason than this: packaging and installing software can't be done using a simple, single method -there are loads of packages which require packaging/installation steps which are quite out of the ordinary.
If working from scratch, you need to start with what you think might work, and then create and install packages -*lots* and *lots* of packages till you run into problems which force you to re-think, re-write and then re-create and re-install all those packages again using the 'new' package format. of course, anyone with lots of experience with these subjects has an advantage.
It is really interesting -and worth the effort in my case.
Since Puppy can run live, installed or semi-installed it presents some unusual problems which must be dealt with -but these needs explain exactly why someone elses' package format and packaging software may not be adequate.
Even without an adequate package format or with none at all like LFS, build scripts can and should be used. I find it insane to spend hours/days creating a package and not having a script which will exactyl repeat the steps. The lack of real build scripts makes the devs/maintainers job infinitley harder and slower.
Well, that's a start. But why are you putting database files under /usr/lib, which is supposed to be used for architecture-dependent (binary) libraries? Your software needs to be even smarter than the sources - 'make install' can do all sorts of crazy, break-your-system things. So make sure your software is actually doing the Right Thing itself.
Does your program handle sources which use 'waf' or 'scons' to configure and build the prog/lib? How about perl, python, tcl, imake, cmake -or any of the others? What about all the sources which don't support DESTDIR -or any of the similar variables. Let's see... where is that list of those DESTDIR alternatives??
I really don't mean to discourage you, but you should be aware that the subject is *quite a lot* deeper than it looks at first glance. If it *were* so simple, then we wouldn't have all the alternatives around that fit various purposes. The package-creation software is really complex compared to package-handling -even including dependency-resolution. The package software needs to be able to create packages which contain all that info, from a wide variety of sources types. The package format itself is the easiest part of the 'threesome' -so that's where you'll make the most changes. The details of the format determine how hard your package-creation and package-handling software have to work.
As a first thought, why are you using 'cp' to copy files from a temporary directory instead of tarring them directly into '/'. Using 'cp', you still have to remove them after copying. tar will do it one step. Or, even if you have a good reason for untarring into a temp dir, and there are good reasons, Are you aware of possible advantages of using tar to move them into '/', because of the different ways it can handle links, directories and ownership/permissions considerations?
It's a nice thing to chat about...
Does your program handle sources which use 'waf' or 'scons' to configure and build the prog/lib? How about perl, python, tcl, imake, cmake -or any of the others? What about all the sources which don't support DESTDIR -or any of the similar variables. Let's see... where is that list of those DESTDIR alternatives??
I really don't mean to discourage you, but you should be aware that the subject is *quite a lot* deeper than it looks at first glance. If it *were* so simple, then we wouldn't have all the alternatives around that fit various purposes. The package-creation software is really complex compared to package-handling -even including dependency-resolution. The package software needs to be able to create packages which contain all that info, from a wide variety of sources types. The package format itself is the easiest part of the 'threesome' -so that's where you'll make the most changes. The details of the format determine how hard your package-creation and package-handling software have to work.
As a first thought, why are you using 'cp' to copy files from a temporary directory instead of tarring them directly into '/'. Using 'cp', you still have to remove them after copying. tar will do it one step. Or, even if you have a good reason for untarring into a temp dir, and there are good reasons, Are you aware of possible advantages of using tar to move them into '/', because of the different ways it can handle links, directories and ownership/permissions considerations?
It's a nice thing to chat about...
Very nice to hear. As my friend goingnuts said the other day, 'maintaining is not funny'.
I like the arch packaging system and think using pacman is a good idea. It wouldn't be bad to use arch packages as a base -*if you could always be able to find a good point to stop updating*. The rolling-release concept means constant breakage.
However, when using packages from *anybody* else, you'll always run into conflicts where you need a different version of a package, or the same version but with patches or different configuration options. And the more your distro deviates from the 'normal' way, or the 'arch way', etc., the more conflicts you have.
I still think that for any live distro, or any distro that does things very different from 'normal' systems, the only way to go is to have your own toolchain and compile everything yourself. Yes, it is a huge amount of work -even when you an automated or semi-automated system for building/rebuilding. Doing it yourself lets you completely control all options, methods, upgrades, etc.
I like the arch packaging system and think using pacman is a good idea. It wouldn't be bad to use arch packages as a base -*if you could always be able to find a good point to stop updating*. The rolling-release concept means constant breakage.
However, when using packages from *anybody* else, you'll always run into conflicts where you need a different version of a package, or the same version but with patches or different configuration options. And the more your distro deviates from the 'normal' way, or the 'arch way', etc., the more conflicts you have.
I still think that for any live distro, or any distro that does things very different from 'normal' systems, the only way to go is to have your own toolchain and compile everything yourself. Yes, it is a huge amount of work -even when you an automated or semi-automated system for building/rebuilding. Doing it yourself lets you completely control all options, methods, upgrades, etc.