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 Fri 19 Sep 2014, 16:06
All times are UTC - 4
 Forum index » Taking the Puppy out for a walk » Suggestions
The State of Package Management
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 1 of 15 [222 Posts]   Goto page: 1, 2, 3, ..., 13, 14, 15 Next

Should Puppy's package format be changed?
Yes, without backwards compatibility.
28%
 28%  [ 11 ]
Yes, with backwards compatibility.
25%
 25%  [ 10 ]
No, but the PET format should be standardized/stricter.
20%
 20%  [ 8 ]
No, the PET format works fine.
25%
 25%  [ 10 ]
Total Votes : 39

Author Message
noryb009

Joined: 20 Mar 2010
Posts: 539

PostPosted: Fri 20 Jan 2012, 20:02    Post subject:  The State of Package Management  

The current PET package format was created for Puppy 2.14. It was a great format, but over time, it has become more and more outdated. Today, PET the format has become almost useless and needs to be updated, without backward compatibility. The package specification is a guide line, packages are compressed in an inefficient way, and packages cannot be recreated.

The first problem is with the package specification: there isn't one. The specification is more of a guide line. Currently, the package should have a pet.specs file, but it's OK if it doesn't. This is not right, as the package manager has to assume the PET name includes the package name, version and release, and that the package doesn't have any dependencies. Another issue is that even when it has a pet.specs file, it doesn't include critical info such as the architecture, puppy it was built in, or who it was packaged by. This missing info causes many frustrations for end users. The specification needs to be changed and be more strict to avoid many common issues with PET packages.

The second problem is with the way it is packaged. Firstly, it is compressed as a .tar.gz file. A 214MB file can be compressed into a 85MB file. That's good, but xz can compress the same file into a 59MB file, which is 25MB (30%) smaller. If puppy used xz or something similar, the space and bandwidth needs of puppy's repositories would also be 30% smaller. Another issue with the format is that the files inside the package are in a folder, named the full package name (but not always), and sometimes with a "./" at the beginning. It also makes the pet.specs harder to find for scripts, especially if there is another file in the package called "pet.specs". Lastly, the packager is not currently needed to input a package release number or dependencies. These fields currently have almost no use, but without them, a package management system with upgrades and dependency tracking is almost impossible to write. All of puppy's packages should be packaged the same way.

Lastly, there is no way to recreate a PET. There are many reasons why you would want to know how a pet was compiled: compiling a new version of the package, trying to shrink the size of the package, or creating a new repository for a different architecture or puplet. Currently, you have to download the source code, and try to compile it. If there are any errors, you have to search for fixes. This method also looses any patches, enhancements or optimizations that are in the PET. If you are porting puppy to a new architecture, you have to do this for all of puppy's packages. A script based packager would allow for easy rebuilding of puppy packages. A script packager would read from a special file and create the package without human interaction. Puppy is the only distribution in distrowatch's top 10 that doesn't have a script based packager. A script based packager would simplify puppy's package management, and save a lot of time for packagers.

So, what has to be done? The PET system has to be forgotten, and a new format be created. While this would mean that many years of packages would become useless, it would allow puppy have a new start, without trying to balance old packages with new packages. The new format should not be specified by whoever creates the package manager, but by the packagers who will have to work with the new format. The specification should be strict, and be built to stand up to the test of time.

Last edited by noryb009 on Mon 23 Jan 2012, 20:18; edited 1 time in total
Back to top
View user's profile Send private message 
p310don

Joined: 19 May 2009
Posts: 705
Location: Brisbane, Australia

PostPosted: Sat 21 Jan 2012, 09:51    Post subject:  

@noryb009

I am pretty dumb when it comes to pet packaging etc, but what you say makes sense. The only thing, you say that if we changed from .pet the previous packages won't work.

If your implementation was taken on board, does it have to not work? The old .pup files can often be made to work, why not .pets. It would be a shame to lose so much stuff.

From a strict user POV, I see the versioning and dependency part as being very useful. I am committed to using puppy, but I can see the frustration would piss off a lot of new users who like to click and it works. There have been many times I've clicked on a pet for something, and it doesn't work for whatever reason. For many that would be enough to hop off to another distro. If it were in the package to "know" if it wasn't going to work, and how to maybe make it work (dependencies) could be very helpful.
Back to top
View user's profile Send private message 
noryb009

Joined: 20 Mar 2010
Posts: 539

PostPosted: Sat 21 Jan 2012, 10:09    Post subject:  

Quote:
If your implementation was taken on board, does it have to not work? The old .pup files can often be made to work, why not .pets. It would be a shame to lose so much stuff.


PET files can work with the new system, but they shouldn't. The main reasons are that it would slow down adoption of the new system, and it cause problems with dependencies and version tracking.

If the new system is successful, you wouldn't need a PET file to install a program. All the programs would either have a package available or have a build script. However, at the beginning this won't be the case, and using PET files may be necessary, but support has to drop after build scripts are created for most of the common programs.
Back to top
View user's profile Send private message 
noryb009

Joined: 20 Mar 2010
Posts: 539

PostPosted: Mon 23 Jan 2012, 20:14    Post subject:  

I guess I never asked a question in my first post:
1) Do you think puppy should get a new package format?
2) If a new format is created, what would you like to see in it?
Back to top
View user's profile Send private message 
emil

Joined: 10 Nov 2009
Posts: 618
Location: Austria

PostPosted: Tue 24 Jan 2012, 03:16    Post subject:  

Hi,
We should not forget that Puppy always tried to incorporate other packages (slackware, debs etc). The whole woof project was an attempt to draw on the repositories of other distros. It was not completely successful (but it was a success IMHO), because the puppy base is not 100% compatible with the other distros bases - so at some points there will be package conflicts / failures.

I observed that package management has given many people cause for turning to new directions - most recent examples:
1) Big Bass created TXZ puppy and now turned to Porteus which uses slackware packages.
2) Iguleder has created his own system of build scripts and repositories (also a woof-like system) and is now working on his own "fork" of puppy http://www.dimakrasner.com/drupal/,http://www.murga-linux.com/puppy/viewtopic.php?t=69248
3) Sickgut has his "Pussy" Linux, which is a slimmed debian live system, but apt-get compatible to the debian stable repos.
4) Last. but not least Warry, Racy and now Saluki have all the same T2 base, so it is somehow a "back to the roots" - while they will not easily draw on a foreign repos they will have the ability to share many packages.

On one side I see the great benefits of either beeing 100% compatible to a foreign repo or creating a new "strict" Puppy package format, I have my doubts on the other side. Is it still a puppy if it is made 100% compatible to another distro? And will the puppy spirit remain the same if there are "not-puppy-like" strict rules for package creation and possibly a review process? Who would be "in charge"?

Becomming professional while keeping playfull and "childish" is a walk on a knifes edge.
I would vote for a backward compatible system, but it will be difficult to create. Becomming a downstream project of other distros (e.g. debian, like "Pussy") would be easiest, but: do we want that? And - last but not least - what does BK say Question
emil
Back to top
View user's profile Send private message Visit poster's website 
Lobster
Official Crustacean


Joined: 04 May 2005
Posts: 15117
Location: Paradox Realm

PostPosted: Tue 24 Jan 2012, 05:42    Post subject:  

In Ye Olde Days, we Puppy users just made do with what we were given . . . Barry and others might compile a program, test it and say it was available.
Then the .pup was introduced as little more than a tar zip file
.pet which was considered overkill, is now the standard and very good too . . .

Quote:
xz or something similar

That extra 30% compression sounds yummy

There is a way we can do this to avoid confusion
Use the new standard on ARM processors to start with
http://puppylinux.org/wikka/PARM

We could use .debs which are compressed if the PARM project becomes a Upup (similar to Lucid) or Dpup compile . . .
http://en.wikipedia.org/wiki/Deb_%28file_format%29

Are there advantages to having our own Puppy debs (optimised and junk removal offered)? Maybe so . . .

I believe Android, Apple and Ubuntu have got package manage right
scroll through packages. Install or uninstall.

How many packages should Puppy have?
All of them.
One other point; I did install a package in Saluki 008
- it was very well implemented. No need to restart x.
Maybe Jemimah will offer some tips . . .

_________________
Puppy WIKI
Back to top
View user's profile Send private message Visit poster's website 
darkcity


Joined: 23 May 2010
Posts: 2452
Location: near here

PostPosted: Tue 24 Jan 2012, 07:58    Post subject:  

the quality of the package is down to the compiler's knowledge and skill.

IMO There are two puppy ideas which can re-enforce each other-

(A) to create a simple easy-to-use slimline OS which is hassle free

(B) to create an OS which people can experiment and learn development techniques

----

So how could this work? here's an example-

Quote:
When you load a PET file it is verified against certain standards.

It fails, for example if PET spec file is missing, then a warning is given 'Package may be non standard (pet-spec file missing) load anyway'?


In case (A)-
You say NO thanks I only want Packages that are known to work and tested - I don't want to be messing around in config files, using terminal etc.

In case (B)-
You say YES okay, if I know the author I will alert him/her to their nooby mistake.

---

Another way to manage quality is have a page for PETs where they can be rated by uses, like wordpress does-
http://wordpress.org/extend/plugins/sopa-blackout/

---

C) is there any technical reason why different compression techniques can't be used in Packages - including XZ.


---

D) what about SFS I've had a lots of trouble using these. Including breaking CUPS and messing up fonts.

Arrow

_________________
helping Wiki for help | IF SendSpace link = "dead" THEN PM me ("up file to http://meownplanet.net/")
Back to top
View user's profile Send private message Visit poster's website 
RSH


Joined: 05 Sep 2011
Posts: 2420
Location: Germany

PostPosted: Tue 24 Jan 2012, 17:20    Post subject: The State of Package Management  

DELETED!
Last edited by RSH on Tue 24 Jan 2012, 20:45; edited 1 time in total
Back to top
View user's profile Send private message 
Karl Godt


Joined: 20 Jun 2010
Posts: 3972
Location: Kiel,Germany

PostPosted: Tue 24 Jan 2012, 19:43    Post subject:  

tar has got the -J, --xz option and it might be not too difficult to implement it into petget .

tar also has got the --backup[=CONTROL] backup before removal, choose version CONTRO=t, numbered make numbered backups

which i have already implemented at one puppy installation .

.pxz .pet2 .peto .peta would give a larger variety to compress ... something to chew on the code .

pxz would be a large step , bzip2 would be the next step after gzip .

*

I would also like the idea of a pre-install.sh .

It is possible to install to /tmp first and let the post-install.sh do the rest , but i have not seen it much .

*

It would be convenient to offer a second button in the Xdialog asking to install : DO YOU WANT TO LOOK INTO THE PET FIRST ?

IF yes then cp pet /tmp ;pet2tgz pet; tar xzf tarredpet; rox /tmp; fi;exit
Back to top
View user's profile Send private message Visit poster's website 
noryb009

Joined: 20 Mar 2010
Posts: 539

PostPosted: Thu 26 Jan 2012, 00:01    Post subject:  

Quote:
And will the puppy spirit remain the same if there are "not-puppy-like" strict rules for package creation and possibly a review process? Who would be "in charge"?

Making stricter rules for package creation isn't really for the developers, it's for the end users who rely on PET files to get their software.

The puppy spirit will remain alive, but it's hard to tell. Stricter rules wouldn't effect the packager too much - it would just be a slightly different way of compressing the program. There will be lots of work to do for the developers, there is always tweaks to be done to packages and bytes to trim.

Quote:
.pet which was considered overkill, is now the standard and very good too...

It is a good idea (.tar.gz with an md5 sum on the end, with package specifications inside), but it hasn't been used correctly (mostly the dependency field), and has become outdated.

Quote:
Use the new standard on ARM processors to start with

It would be great to start on ARM with a new package format, but it could also slow things down considerably. It would be better to support both (and x86_64 also?) from the beginning, as it would allow everyone to contribute.

Quote:
We could use .debs which are compressed if the PARM project becomes a Upup (similar to Lucid) or Dpup compile...

We could use another package format, but I don't know if it would "work" for puppy, mostly due to puppy's size commitments.

Quote:
Another way to manage quality is have a page for PETs where they can be rated by uses, like wordpress does

People should definitely be able to submit bugs to the packager, but I think rating would work well. Packages either work or they don't, and if they don't, they should be fixed.

Quote:
C) is there any technical reason why different compression techniques can't be used in Packages - including XZ.

As far as I know, there isn't any real technical reason. The packages just wouldn't work on puplets before support was added.

Quote:
D) what about SFS I've had a lots of trouble using these. Including breaking CUPS and messing up fonts.

I think the best way for SFS to be handled is to remove them from online repositories and let users generate their own from multiple large packages. SFSes are great if you need some programs in a lot of puppies which are installed frugally, but they are horrible for full installs, or if you run into the SFS limit. Having users generate their own would let them decide what they want and remove the rest, instead of some of the "theme" SFSes, which have many packages you don't need. It doesn't make sense to have to host 2 copies of packages (PET and SFS) either.

Quote:
tar also has got the --backup[=CONTROL] backup before removal, choose version CONTRO=t, numbered make numbered backups

Packages shouldn't touch files that don't belong to them, though. There could be scripts that need that special version of the file - it's bad if you are locked out of puppy because you installed a package that moved a library that bash needs. This also causes multiple copies of files, which can add up quickly if you have limited disk space.

Quote:
pxz would be a large step, bzip2 would be the next step after gzip.

I don't see why we should use bzip2 because it's the "next step". XZ has a better compression ratio, so why should we have to go through the trouble of changing the standard twice, resulting in more backward compatibility code?

Quote:
I would also like the idea of a pre-install.sh.

I would also like a better package install/remove format, which the pinstall.sh and puninstall.sh, along with any new scripts, are in one file, which would allow them to share code. The file would just have functions pinstall(), puninstall()... or something.

Quote:
It would be convenient to offer a second button in the Xdialog asking to install : DO YOU WANT TO LOOK INTO THE PET FIRST?

I think that anyone who wants to look into a PET file would know how to extract it manually. Every user shouldn't have to click "no" every time they install something to save developers a few seconds.
Back to top
View user's profile Send private message 
amigo

Joined: 02 Apr 2007
Posts: 2247

PostPosted: Thu 26 Jan 2012, 02:43    Post subject:  

Changing the type of compression used won't help the mess at all -it'll just make it possible to fit more mess in less space. A working package format specification *is* a lot trouble for packagers -unless the package spec is accompanied by tools which make it possible to create packages which conform to the spec -preferably easily.

src2pkg provides the tool which includes the tricks needed to make packages smaller, etc. My new 'tpkg' package format provides all the extra stuff needed to permit depends resolution, verification of each file installed, sane upgrade/removal of any package, authorization of package builder and lots more. All that is provided automatically by src2pkg -even dependency resolution for script programs.
Back to top
View user's profile Send private message 
Karl Godt


Joined: 20 Jun 2010
Posts: 3972
Location: Kiel,Germany

PostPosted: Fri 27 Jan 2012, 11:08    Post subject:    

Quote:
Quote:
tar also has got the --backup[=CONTROL] backup before removal, choose version CONTRO=t, numbered make numbered backups

Packages shouldn't touch files that don't belong to them, though. There could be scripts that need that special version of the file - it's bad if you are locked out of puppy because you installed a package that moved a library that bash needs. This also causes multiple copies of files, which can add up quickly if you have limited disk space.

Quote:
pxz would be a large step, bzip2 would be the next step after gzip.

I don't see why we should use bzip2 because it's the "next step". XZ has a better compression ratio, so why should we have to go through the trouble of changing the standard twice, resulting in more backward compatibility code?

Quote:
I would also like the idea of a pre-install.sh.

I would also like a better package install/remove format, which the pinstall.sh and puninstall.sh, along with any new scripts, are in one file, which would allow them to share code. The file would just have functions pinstall(), puninstall()... or something.

Quote:
It would be convenient to offer a second button in the Xdialog asking to install : DO YOU WANT TO LOOK INTO THE PET FIRST?

I think that anyone who wants to look into a PET file would know how to extract it manually. Every user shouldn't have to click "no" eve
ry time they install something to save developers a few seconds.


Code:
--- /mnt/+JUMP-6+luci-218.sfs/usr/local/petget/petget   2010-06-16 14:33:36.000000000 -0100
+++ /usr/local/petget/petget   2012-01-27 13:59:02.000000000 -0100
@@ -17,6 +17,8 @@
 
 [ ! $1 ] && exit
 
+mkdir -p /tmp/PetGet  ##+++2011_10_25
+
 export LANG=C
 . /etc/DISTRO_SPECS #has DISTRO_BINARY_COMPAT, DISTRO_COMPAT_VERSION
 
@@ -153,14 +155,21 @@ export INSTALL_DIALOG="<window title=\"P
    <text use-markup=\"true\"><label>\"<b>${FULLPKGNAME}</b>\"</label></text>
    <hbox>
     <button ok></button>
+    <button><label>Examine Package</label>
+    <action>EXIT:examine</action></button>
     <button cancel></button>
    </hbox>
   </vbox>
- </window>"
+ </window>"
 RETPARAMS="`gtkdialog3 --program=INSTALL_DIALOG`"
 eval "$RETPARAMS"
-[ "$EXIT" != "OK" ] && exit
+#echo $EXIT
+echo $RETPARAMS
+echo $EXIT
+if [ "$EXIT" != "OK" -a "$EXIT" != "examine" ];then # && exit
+echo "exiting $0";exit;fi
 
+if [ "$EXIT" = "OK" ];then
 #find entry in databases...
 #pkgname|nameonly|version|pkgrelease|category|size|path|fullfilename|dependencies|description|
 #optionally on the end: compileddistro|compiledrelease|repo| (fields 11,12,13)
@@ -181,9 +190,9 @@ fi
 [ "$originPKGPATH" = "$PKGPATH" ] && cp -f ${PKGPATH}/${FULLPKGNAME} ${PKGPATH}/${FULLPKGNAME}-TEMPBACKUP
 
 #install pkg...
-rm -f /tmp/petget_missing_dbentries-Packages-* 2>/dev/null
-rm -f /tmp/petget-installed-pkgs-log 2>/dev/null
-echo "$DB_ENTRY" > /tmp/petget_missing_dbentries-Packages-alien
+rm -f /tmp/PetGet/petget_missing_dbentries-Packages-* 2>/dev/null
+rm -f /tmp/PetGet/petget-installed-pkgs-log 2>/dev/null
+echo "$DB_ENTRY" > /tmp/PetGet/petget_missing_dbentries-Packages-alien
 /usr/local/petget/installpkg.sh $PKGPATH/$FULLPKGNAME
 RETVAL=$?
 
@@ -195,7 +204,7 @@ rm -f $PKGPATH/${PKGNAME}.tar.gz 2>/dev/
 [ "$originPKGPATH" = "$PKGPATH" ] && mv -f ${PKGPATH}/${FULLPKGNAME}-TEMPBACKUP ${PKGPATH}/${FULLPKGNAME}
 
 #announce result...
-if [ $RETVAL -ne 0 -o ! -s /tmp/petget-installed-pkgs-log ];then
+if [ $RETVAL -ne 0 -o ! -s /tmp/PetGet/petget-installed-pkgs-log ];then
  export FAIL_DIALOG="<window title=\"Puppy Package Manager\" icon-name=\"gtk-about\">
   <vbox>
   <pixmap><input file>/usr/local/lib/X11/pixmaps/error.xpm</input></pixmap>
@@ -204,12 +213,12 @@ if [ $RETVAL -ne 0 -o ! -s /tmp/petget-i
     <button ok></button>
    </hbox>
   </vbox>
- </window>"
+ </window>"
  gtkdialog3 --program=FAIL_DIALOG
  exit
 fi
 
-INSTALLEDMSG="`cat /tmp/petget-installed-pkgs-log`"
+INSTALLEDMSG="`cat /tmp/PetGet/petget-installed-pkgs-log`"
 MENUMSG=""
 INSTALLEDCAT="`echo -n "$INSTALLEDMSG" | rev | cut -f 1 -d ' ' | rev`"
 if [ "$INSTALLEDCAT" = "none" ];then
@@ -218,7 +227,7 @@ else
  MENUMSG="<text><label>...look in '${INSTALLEDCAT}' in the menu (bottom-left of screen) to run the application.</label></text>"
 fi
 
-#installpkg.sh will have logged to /tmp/petget-installed-pkgs-log
+#installpkg.sh will have logged to /tmp/PetGet/petget-installed-pkgs-log
 export INSTALL_DIALOG="<window title=\"Puppy Package Manager\" icon-name=\"gtk-about\">
  <vbox>
  <pixmap><input file>/usr/local/lib/X11/pixmaps/ok.xpm</input></pixmap>
@@ -256,4 +265,32 @@ fi
 
 kill $X3PID
 
+else
+#PKGPATH="`dirname "$PASSEDPARAM"`"
+#FULLPKGNAME="`basename "$PASSEDPARAM"`"
+#PASSEDBASE="`basename "$PASSEDPARAM"`"
+FULLPKG="${FULLPKGNAME%\.*}";echo $FULLPKG
+EXTN="${FULLPKGNAME##*.}";echo $EXTN
+mkdir -p /tmp/"$FULLPKG"
+cp "$PKGPATH/$FULLPKGNAME" /tmp/"${FULLPKG}"/
+cd /tmp/"${FULLPKG}"/
+case $EXTN in
+pet)
+pet2tgz ${FULLPKGNAME}
+tar xzf ${FULLPKG}.tar.gz
+rox /tmp/"${FULLPKG}"/
+xmessage -buttons "OK :140, Delete:141" "Click Delete button to erase this
+examination directory ,
+otherwise just OK"
+if [ "$?" = '141' ];then
+rox -D /tmp/"${FULLPKG}"/
+rm -rf /tmp/"${FULLPKG}"/
+fi
+;;
+*)
+xmessage -bg red "$EXTN examination not yet implemented"
+;;
+esac
+exec petget "$PASSEDPARAM"
+fi
 ###END###
Back to top
View user's profile Send private message Visit poster's website 
Aitch


Joined: 04 Apr 2007
Posts: 6825
Location: Chatham, Kent, UK

PostPosted: Fri 27 Jan 2012, 12:39    Post subject:  

If the PPM is to be changed, are we bound to consult Barry K, or is this all part of the community's ability to sustain itself and continue growing, whilst giving him breathing space/time?

I like the idea of improving the package manager, as I have to admit to not having the skillset to resolve problems if and when they occur....I just try something else, or accept it , if it doesn't work - Package management overhaul seems overdue since 2.14 or so

I think the most frustrating thing is the end-user inability to find out what to do IF something doesn't install, or if something is uninstalled, something else breaks - where are the on-screen help messages?
I had hoped SFSs were going to provide a solution, but not so far

I have to say, the people showing most promise, from my limited perspective are amigo, iguleder, technosaurus, big_bass, [though he may have moved on], and jemimah [apologies if I haven't noticed your skills/mentioned you]

I would love puppy to become a distro which uses a minimalist full feature kernel, [or instructions how to modify it], with a packaging setup that allowed me to install ANY suitable source code, and make it puppy compatible, with dependency hell taken care of automatically, or install a ready built program/dotpet/SFS knowing which kernel it will work with and letting me know if it isn't suitable, whilst telling me what to find that IS suitable!
...and which could be updated/maintained using a standard linux format filesystem, AND that could be transferred to a different hardware base - ARM/PPC, IF I so chose
.....are we at least working towards it?
or still going in separate directions?

Perhaps a few explanations about essentials like gcc, libc and gtk versions, static/dynamic builds, compressions, filesystems etc [I think...?] would help end users understand the problems a bit, and not have such high expectations....it's not, after all, my intention to put devs under pressure....but I don't know what else I can do to help, other than the research, posting and ideas offered that I already do
Are puppy/linux devs aware of a linux equivalent of a program I used back in win98 days called Dependency Walker?
I posted a link for jemimah recently which looked similar

http://www.murga-linux.com/puppy/viewtopic.php?p=598868#598868

I think we are amazingly lucky really that puppy works as well as it does, considering the sheer lack of standardised process control in place, in both puppy and linux in general! Laughing - thanks Barry/devs!

Has anyone ever done a sequence diagram/flow chart of puppy so we might know what it ought to be doing? [headings, with features/functions would do?]
I know grub got discussed, but again, I don't recall a final collated version.... Sad

My current biggest problem isn't puppy, AT ALL, ...... it's finding a browser/flash combination that is usable AND crash-free, which lets me browse/search/email etc, yet doesn't encroach on my freedom and collate my browsing lifestyle for some snoop/corporation/FBI to use against me !!

Aitch Smile
Back to top
View user's profile Send private message 
noryb009

Joined: 20 Mar 2010
Posts: 539

PostPosted: Sat 28 Jan 2012, 18:54    Post subject:  

Quote:
If the PPM is to be changed


The PPM shouldn't be changed, it should be removed. Changing PPM would either make a few features impossible to implement, or cause some scripts to not work right.

Quote:
My current biggest problem isn't puppy, AT ALL, ...... it's finding a browser/flash combination that is usable AND crash-free, which lets me browse/search/email etc

You might find a browser/flash combination that works, but it wouldn't be possible to recreate the package. A script based packager would allow previous workarounds and patches to be recorded and used again.

Quote:
yet doesn't encroach on my freedom and collate my browsing lifestyle for some snoop/corporation/FBI to use against me !!

There is currently no way to know what is in the packages you download, unless you compile it yourself. You don't know if the packager added something malicious to the code (random people post PETs on this forum), or if somebody switched the packages on the server (packages aren't signed). This is another big problem with the package system currently used.

Just wanted to post this:
tytower wrote:
I uninstalled all that i had downloaded.
However while it was removing those it also deleted all shared objects files so now I don't have a lot of standard library files there that should be !!
Surely such a basic as not deleting shared objects CAN'T be overlooked but it is in 5.3

(link)
Back to top
View user's profile Send private message 
jemimah


Joined: 26 Aug 2009
Posts: 4309
Location: Tampa, FL

PostPosted: Sat 28 Jan 2012, 19:32    Post subject:  

The problem isn't the ppm, it's the repos.

If J. Random User picks some random package from the Ubuntu repo, downloads 300MB worth of deps overwriting system files in the process, what do you think is going to happen?

Or if J Random User downloads some random package from some random puppy site, probably not even meant for his/her version of puppy, any wonder why it's difficult to track down the dependencies?

The only way any of this works at all is if puppy developers compile and test the packages, and specify the dependencies correctly, and if the users stick to installing stuff from the tested repositories only.

Puppy is a pint-sized and very finicky OS. Trying to use packages from other repos is asking for trouble.
Back to top
View user's profile Send private message Visit poster's website 
Display posts from previous:   Sort by:   
Page 1 of 15 [222 Posts]   Goto page: 1, 2, 3, ..., 13, 14, 15 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Taking the Puppy out for a walk » Suggestions
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.1627s ][ Queries: 15 (0.0064s) ][ GZIP on ]