[IMPORTANT] Package manager for next release

[Falcony]

So two solution:

1-st - rules of creation of packages, uncentralized users repository and strict package manager strictly checks packets and depends
2-nd - rules of creation of packages, centralized distro repository, number of users checks packets and depends, update database
3-nd - leave as is. Also solution L) Soon will be as Tomas M have

[francois]

It may really be an improvement to add 'dependencies' section to (for example) /var/log/packages/* file.

Protes module could have (and for big modules like base - always it is) several number Slackware packages inside

So better if we competely separate Proteus modules and Slackware packages iinformation

Why do not have special directory for example

/var/proteus

to store Proteus modules information?

And in the same time /var/log/packages/* will be as it is now


So for example if we have application installed in a system then we have module information records in

/var/proteus/directory

number some files files for ex. :

/var/proteus/directory/CONFICTS - with what lzm modules it conflicts
/var/proteus/directory/DEPENDS - what modules it required
/var/proteus/directory/LINKS - list of repos/mirrors depens could be downloaded
/var/proteus/directory/DESC - desciption of module
/var/proteus/directory/INCLUDE - from what what slackware packages it is consists(the lists)
/var/proteus/directory/MAINTAIN - Maintainer info
...etc

...

This looks quite much like the slapt-get file structure, citation from FAQ10, see hyperlink:
http://software.jaos.org/git/slapt-get/plain/FAQ

10. What about package dependencies?

First of all, slapt-get does not provide dependency resolution for vanilla
Slackware packages (ie, official Slackware packages that come with the
distribution).

However, slapt-get does provide a framework for dependency resolution for
packages that follow the Slackware package format, while still being backwards
compatible. This information is stored in so called meta files within the
package. slapt-get does not parse the packages themselves. It uses the
PACKAGES.TXT package database that Patrick Volkerding provides along with his
packages. slapt-get uses this file by extending it with optional extra fields.
This information is stored within the package simply as a means of easy
transport, to later be parsed into a PACKAGES.TXT. For example, the entry
for man within PACKAGES.TXT looks like:

PACKAGE NAME: man-1.5l-i386-1.tgz
PACKAGE LOCATION: ./slackware/ap
PACKAGE SIZE (compressed): 166 K
PACKAGE SIZE (uncompressed): 390 K
PACKAGE DESCRIPTION:
man: man (format and display the on-line manual pages)

It is extended like so:

PACKAGE NAME: man-1.5l-i386-1.tgz
PACKAGE MIRROR: http://www.slackware.at/data/slackware-9.1/
PACKAGE LOCATION: ./slackware/ap
PACKAGE SIZE (compressed): 166 K
PACKAGE SIZE (uncompressed): 390 K
PACKAGE REQUIRES: groff >= 1.56-noarch-1,man-pages | man-pages-de
PACKAGE CONFLICTS:
PACKAGE SUGGESTS:
PACKAGE DESCRIPTION:
man: man (format and display the on-line manual pages)

The REQUIRES line is an addition supported by slapt-get, along with CONFLICTS
and SUGGESTS. The meta files supporting dependencies, conflicts, and
suggestions are within the packages inside the ./install/ directory. The
REQUIRES information is stored in the slack-required file. The CONFLICTS
information is stored within the slack-conflicts file. The SUGGESTS
information is stored in the slack-suggests file. See FAQ #19 for a breakdown
of the structure of REQUIRES, FAQ #31 for CONFLICTS, and FAQ #44 for SUGGESTS.
...

Packages supporting this framework can be found at linuxpackages.net, along
with several Slackware derived distributions such as CollegeLinux (starting
with 2.5) and VectorLinux (starting with 5.0).

Also, Stefano Stabellini has created a PACKAGES.TXT that contains the
dependency information for Slackware packages without modifying the actual
packages themselves. This can be used as a slapt-get source to pull the
packages from official slackware.com mirrors. Read more about it at
Stefano's page: http://www.stabellini.net/depslack.html

Wouldn't it be a good idea to make porteus modules data info compatible with slax-get syntax^

[brokenman]

"slapt-get does not parse the packages themselves. It uses the PACKAGES.TXT package database that Patrick Volkerding provides"

This is EXACTLY what i suggested. My last package manager relied heavily on the this system (dependencies listed in PACKAGES.TXT) and it worked well. Having each module with meta files in /var/proteus would make it easier to append the universal PACKAGES.TXT file but would create extra work for the module makers. I believe with a good server side script, no /var/porteus/dependencies would be needed.

[Falcony]

No matter how module creator make module - it could be done via converting Slackware packages, slapt-get, via SlackBuild building, via CRUX-ports, Arch LInux ABS or converting deb package from Debian or just make install. This is internal module creator business.

But If a module is not intended for internal usage - module creator have to provide nessary information - what software incuded, what versions, depends, conflict, etc

PACKAGE NAME: man-1.5l-i386-1.tgz
PACKAGE MIRROR: http://www.slackware.at/data/slackware-9.1/
PACKAGE LOCATION: ./slackware/ap
PACKAGE SIZE (compressed): 166 K
PACKAGE SIZE (uncompressed): 390 K
PACKAGE REQUIRES: groff >= 1.56-noarch-1,man-pages | man-pages-de
PACKAGE CONFLICTS:
PACKAGE SUGGESTS:
PACKAGE DESCRIPTION:
man: man (format and display the on-line manual pages)

This is information handled for Slackware only.

For Porteus we have lzm modules which have different nature of usage and structure. In Porteus groff and man is just internal application inside 001-core.sq4.lzm. All upper level application which has groff as depends have to refer not to groff but to 001-core.sq4.lzm

My last package manager relied heavily on the this system (dependencies listed in PACKAGES.TXT) and it worked well.

I beliave it worked well - as most of I builded from CRUX-ports, SlackBuilds and Arch ABS/AUR.

Dependencies listed in PACKAGES.TXT, Pkgfile, PKGBUILD, *.Slackbuild - dependencies of Slackware, CRUX Linux and Arch packages.

It is not for Porteus modules

Such situation when modules activated and deactivated on fly - not rare one

Or when user use modules from two differnet package providers who builded different version of same software.

Or when one provider create one big module with all libararies included and other provider created several small modules which version after activattion could make big module of first provider unusable

[francois]

"slapt-get does not parse the packages themselves. It uses the PACKAGES.TXT package database that Patrick Volkerding provides"

This is EXACTLY what i suggested. My last package manager relied heavily on the this system (dependencies listed in PACKAGES.TXT) and it worked well. Having each module with meta files in /var/proteus would make it easier to append the universal PACKAGES.TXT file but would create extra work for the module makers. I believe with a good server side script, no /var/porteus/dependencies would be needed.

I am sure I did not use your package manager up to its complete possibilities. Can you tell us a little more about it briefly, if you may? Is there some improvement to be done to take into account falcony's suggestion of documenting the modules produced, or do you find it unecessary?

[fanthom]

what about using 'slapt-get' + 'gslapt' which could point to Porteus repo with lzm modules?
gslapt looks really nice:
http://forum.porteus.org/viewtopic.php?f=46&t=136
the only matter would be to create packages.db (containing our lzm's) which is readable by slapt-get.
Having package manager with GUI is probably most demanded feature by new people

[beny]

hi fanthom,slapt-get package manager is a very powerful, that does not just look for the packages but also serves to upgrade the system, improper operation may cause serious damage, but with the gui I think you can rest easy.

[fanthom]

@beny
i know that you can destroy your system (especially Porteus which has plenty of non standard slackware packages). but slapt-get with porteus repo only should be ok. Just need to warn users to not add any other repos - this may be hard

[X-Factor]

@all
Well to have a quality product (especially if we want to rule the world ) we have to be firm with standards there are many example with non standard issue IMHO.

[brokenman]

I am sure I did not use your package manager up to its complete possibilities. Can you tell us a little more about it briefly, if you may?

It used the slacky and another repo to download packages. First it checked the PACKAGES.TXT file for dependencies and if none were present on the system it downloaded them, converted & activated them before then downloading the main package and building it from source locally. It relied heavily on PACKAGES.TXT. I stopped developing it when someone else produced a usable GUI package manager (sorry forgot name).

What i originally imagined for Porteus was two files on the server for each module. The module itself and an index file (not necessarily inside the module) that contained it's name, version, description & libraries. A server side script could create a PACKAGES.TXT once a week with info from everything. The local package manager could then download the chosen module, ldd the required files and search the PACKAGES.TXT for the dependencies required and download them.

I'm sure there is a better method, this was just a theory. I like the idea of pimping slacky to do what we need.

I am in favour of having a handful of module monitors that check or create the module following strict guidelines, however we know from other places that it is labour intesive and could fall apart eventually. Including all dependencies in every module would ensure they all work, but is overkill for people that already have 90% of the required deps activated. It makes for large modules and chews up server space uneccessarily.

I will be watching this thread closely. Hopefully we can get something sorted together and find a great solution.

[francois]

what about using 'slapt-get' + 'gslapt' which could point to Porteus repo with lzm modules?
gslapt looks really nice:
http://forum.porteus.org/viewtopic.php?f=46&t=136
the only matter would be to create packages.db (containing our lzm's) which is readable by slapt-get.
Having package manager with GUI is probably most demanded feature by new people

Gslapt is for sure a lot more intuitive. It looks like synaptic. It is more easy to understand when something goes wrong.

Is there any reason that a lzm package could not be recognized as a normal or standard package by slapt-get or gslapt? I have the impression using slapt-get, that most of the time they are recognized as such.

[brokenman]

OK lets start talking about the strict format for creating modules. I'd like to start getting a few modules onto the server as soon as possible.

I'll start off with:

Modules should be created in the same way that one would create a slax module with the following addition. A file should reside in /var with the following info:

Code: Select all

date: yymmdd
name: one line
version: one line
description: 8 lines
##
##
##
##
##
##
##
##
deps: one-continuous line with filename=>version:filename=>version:
files: list of files in the module, one per line.

Using this premise a script could quite easily take care of generating the file, and a client side manager could easily search for dependencies and give a report. Please give your opinions and suggestions where valid.

[ponce]

http://www.stabellini.net/requiredbuilder.html

http://connie.slackware.com/~alien/tool ... s_files.sh
I use this for my repos, maybe can be adapted for deps.

I have done a slack minimal install for installing things later with slapt-get with auto-deps resolving (to do a "slapt-get --install httpd", for example) for the base slackware64-13.1 packages: for this I adapted (with some manual editing) stabellini's depslack (that was for x86).

[fanthom]

@brokenman

i have created sample package with txz2lzm tool. you can get it from here:
http://www.mediafire.com/?rdr54w7c6x4sgad

required deps are copied from here:
http://slackfind.net/en/packages/search ... stversion=

generated info file /var/nmapsi4-0.2-i486-1sl

name: nmapsi
version: 4-0.2-i486-1sl
description:
nmapsi4: NmapSi4 (Qt4 Nmap Interface)
nmapsi4: NmapSi4 is a complete Qt-based Gui with the design goals to provide
nmapsi4: a complete Nmap interface for Users, in order to management all
nmapsi4: options of this powerful security net scanner!
deps: cxxlibs >= 6.0.13-i486-2 | gcc-g++ >= 4.4.4-i486-1,expat >= 2.0.1-i486-1,fontconfig >= 2.8.0-i486-1,freetype >= 2.3.12-i486-1,gcc >= 4.4.4-i486-1,glib2 >= 2.22.5-i486-1,glibc-solibs >= 2.11.1-i486-3,libICE >= 1.0.6-i486-1,libSM >= 1.1.1-i486-1,libX11 >= 1.3.3-i486-1,libXau >= 1.0.5-i486-1,libXdmcp >= 1.0.3-i486-1,libXext >= 1.1-i486-1,libXrender >= 0.9.5-i486-1,libpng >= 1.4.3-i486-1_slack13.1,libxcb >= 1.6-i486-1,mesa >= 7.8.1-i486-1,qt >= 4.6.2_2d3d3e5-i486-1,sqlite >= 3.6.23.1-i486-1,util-linux-ng >= 2.17.2-i486-1,zlib >= 1.2.3-i486-2
files:
/var/nmapsi4-0.2-i486-1sl
/var/log/scripts/nmapsi4-0.2-i486-1sl
/var/log/packages/nmapsi4-0.2-i486-1sl
/usr/share/nmapsi4/locale/nmapsi4_pt_BR.qm
/usr/share/nmapsi4/locale/nmapsi4_pl.qm
/usr/share/nmapsi4/locale/nmapsi4_it.qm
/usr/share/nmapsi4/locale/nmapsi4_fr.qm
/usr/share/nmapsi4/locale/nmapsi4_es.qm
/usr/share/nmapsi4/locale/nmapsi4_de.qm
/usr/share/nmapsi4/locale/nmapsi4_cs.qm
/usr/share/nmapsi4/locale/nmapsi4-logr_pl.qm
/usr/share/nmapsi4/locale/nmapsi4-logr_it.qm
/usr/share/nmapsi4/locale/nmapsi4-logr_fr.qm
/usr/share/nmapsi4/locale/nmapsi4-logr_es.qm
/usr/share/nmapsi4/locale/nmapsi4-logr_de.qm
/usr/share/nmapsi4/locale/nmapsi4-logr_cs.qm
/usr/share/icons/hicolor/64x64/apps/nmapsi4.png
/usr/share/icons/hicolor/32x32/apps/nmapsi4.png
/usr/share/icons/hicolor/16x16/apps/nmapsi4.png
/usr/share/icons/hicolor/128x128/apps/nmapsi4.png
/usr/share/applications/kde/nmapsi4.desktop
/usr/share/applications/kde/nmapsi4-logr.desktop
/usr/share/applications/kde/nmapsi4-admin.desktop
/usr/doc/nmapsi4-0.2/Translation
/usr/doc/nmapsi4-0.2/TODO
/usr/doc/nmapsi4-0.2/SlackBuild/slack-desc
/usr/doc/nmapsi4-0.2/SlackBuild/nmapsi4.SlackBuild
/usr/doc/nmapsi4-0.2/README
/usr/doc/nmapsi4-0.2/NEWS
/usr/doc/nmapsi4-0.2/COPYING
/usr/doc/nmapsi4-0.2/AUTHORS
/usr/bin/nmapsi4-logr
/usr/bin/nmapsi4

are you happy with this or what should be changed?
If module contains several packages - should we create info file for each package or rather one info file for whole module?
This is only sample and deps should be tracked by some tool incorporated in your Porteus-Module-Tools and not copied from the website

@ponce
I have tried 'requiredbuilder' package suggested by you but it tracked only libs and not binaries. tried on transmission package unpacked to a folder and got no output from 'requiredbuilder'. did i miss something?

[ponce]

slacky people use it in their standard slackbuilds: look at the options, it should generate a slack-required file.

http://repository.slacky.eu/slackware-1 ... SlackBuild

http://repository.slacky.eu/slackware-1 ... k-required