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

The time now is Mon 20 Oct 2014, 06:20
All times are UTC - 4
 Forum index » House Training » Users ( For the regulars )
.
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 1 of 2 [17 Posts]   Goto page: 1, 2 Next
Author Message
simargl

Joined: 11 Feb 2013
Posts: 572

PostPosted: Thu 04 Jul 2013, 10:28    Post subject:  .  

.
Last edited by simargl on Sun 01 Sep 2013, 11:57; edited 2 times in total
Back to top
View user's profile Send private message Visit poster's website 
butchydave


Joined: 03 Mar 2012
Posts: 28

PostPosted: Thu 04 Jul 2013, 11:33    Post subject: 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!!
Back to top
View user's profile Send private message 
ally


Joined: 19 May 2012
Posts: 851
Location: lincoln

PostPosted: Thu 04 Jul 2013, 15:21    Post subject:  

^^^^^

me too!

Smile
Back to top
View user's profile Send private message Visit poster's website 
jabu2

Joined: 07 Apr 2008
Posts: 45
Location: Australia

PostPosted: Thu 04 Jul 2013, 23:30    Post subject:  

Simargl

I read your topic title and first message.

In the first sentence, the phrase chosen path to follow could be a problem.

Puppy world does not understand "chosen", "path" or "follow".

Your Alpha is good, could turn out to be an excellent truffle. Thank you.
Back to top
View user's profile Send private message 
simargl

Joined: 11 Feb 2013
Posts: 572

PostPosted: Fri 05 Jul 2013, 04:53    Post subject:  

.
Last edited by simargl on Sun 01 Sep 2013, 11:17; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website 
BarryK
Puppy Master


Joined: 09 May 2005
Posts: 7047
Location: Perth, Western Australia

PostPosted: Sat 06 Jul 2013, 06:51    Post subject:  

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.


Maybe you are describing iguleder's roar-ng, which is fork of Puppy that compiles everything from source.

https://github.com/iguleder/roar-ng-ii
http://www.murga-linux.com/puppy/viewtopic.php?t=75753

_________________
http://bkhome.org/news/
Back to top
View user's profile Send private message Visit poster's website 
darry1966

Joined: 26 Feb 2012
Posts: 475
Location: New Zealand

PostPosted: Sat 06 Jul 2013, 07:44    Post subject: 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.
Back to top
View user's profile Send private message 
simargl

Joined: 11 Feb 2013
Posts: 572

PostPosted: Sat 06 Jul 2013, 09:58    Post subject:  

.
Last edited by simargl on Sun 01 Sep 2013, 11:20; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website 
amigo

Joined: 02 Apr 2007
Posts: 2257

PostPosted: Sat 06 Jul 2013, 14:48    Post subject:  

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.
Back to top
View user's profile Send private message 
simargl

Joined: 11 Feb 2013
Posts: 572

PostPosted: Mon 08 Jul 2013, 03:50    Post subject:  

.
Last edited by simargl on Sun 01 Sep 2013, 11:20; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website 
amigo

Joined: 02 Apr 2007
Posts: 2257

PostPosted: Mon 08 Jul 2013, 13:10    Post subject:  

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.
Back to top
View user's profile Send private message 
simargl

Joined: 11 Feb 2013
Posts: 572

PostPosted: Tue 09 Jul 2013, 02:52    Post subject:  

.
Last edited by simargl on Sun 01 Sep 2013, 11:20; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website 
amigo

Joined: 02 Apr 2007
Posts: 2257

PostPosted: Wed 10 Jul 2013, 08:44    Post subject:  

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...
Back to top
View user's profile Send private message 
simargl

Joined: 11 Feb 2013
Posts: 572

PostPosted: Wed 10 Jul 2013, 11:57    Post subject:  

.
Last edited by simargl on Sun 01 Sep 2013, 11:19; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website 
amigo

Joined: 02 Apr 2007
Posts: 2257

PostPosted: Wed 10 Jul 2013, 12:06    Post subject:  

So, you do have to manually write a 'def' file which defines the build process, etc. How many packages does your OS have? Are you using some sort of base, or using your own toolchain to compile everything?
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 1 of 2 [17 Posts]   Goto page: 1, 2 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » House Training » Users ( For the regulars )
Jump to:  

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


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