Slitaz Install Debian Package From File

But, but — it is not a package manager — it is just a tool that install and remove already download files with.deb format. Seems, SliTaz not uses. It is possible to install Linux onto most of these file systems. The ext file systems, namely ext2, ext3, and ext4 are based on the original Linux file.

Table of Contents

5.1. README.Debian

5.2. compat

5.3. conffiles

5.4. package.cron.*

5.5. dirs

5.6. package.doc-base

5.7. docs

5.8. emacsen-*

5.9. package.examples

5.10. package.init and package.default

5.11. install

5.12. package.info

5.13. package.links

5.14. {package.,source/}lintian-overrides

5.15. manpage.*

5.15.1. manpage.1.ex

5.15.2. manpage.sgml.ex

5.15.3. manpage.xml.ex

5.16. package.manpages

5.17. NEWS

5.18. {pre,post}{inst,rm}

5.19. package.symbols

5.20. TODO

5.21. watch

5.22. source/format

5.23. source/local-options

5.24. source/options

5.25. patches/*

To control most of what debhelper doeswhile building the package, you put optional configuration files under thedebian directory. This chapter will provide an overview ofwhat each of these does and its format. Please read the Debian PolicyManual and Debian Developer'sReference for guidelines for packaging.

The dh_make command will create some template configurationfiles under the debian directory. Most of them come withfilenames suffixed by .ex. Some of them come with filenamesprefixed by the binary package name such aspackage. Take a look at all ofthem.^[54]

Some template configuration files for debhelpermay not be created by the dh_make command. Insuch cases, you need to create them with an editor.

If you wish or need to activate any of these, please do the following:

• rename template files by removing the .ex or.EX suffix if they have one;

• rename the configuration files to use the actual binary packagename in place of package;

• modify template file contents to suit your needs;

• remove template files which you do not need;

• modify the control file (see Section 4.1, “control”),if necessary;

• modify the rules file (see Section 4.4, “rules”), ifnecessary.

Any debhelper configuration fileswithout a package prefix, such asinstall, apply to the first binary package. When there aremany binary packages, their configurations can be specified by prefixing theirname to their configuration filenames such aspackage-1.install,package-2.install, etc.

One of the most annoying things about software is when you spend a great dealof time and effort customizing a program, only to have an upgrade stomp allover your changes. Debian solves this problem by marking such configuration files as conffiles.^[55]When you upgrade a package, you'll be asked whether you want to keepyour old configuration files or not.

dh_installdeb(1)automatically flags any files underthe /etc directory as conffiles, so if your program onlyhas conffiles there you do not need to specify them in this file. For mostpackage types, the only place conffiles should ever be is under/etc, and so this file doesn't need to exist.

If your program uses configuration files but also rewrites them on its own,it's best not to make them conffiles because dpkg willthen prompt users to verify the changes all the time.

If the program you're packaging requires every user to modify the configurationfiles in the /etc directory, there are two popular ways toarrange for them to not be conffiles, keeping dpkg quiet:

• Create a symlink under the /etc directory pointing to afile under the /var directory generated by themaintainer scripts.

• Create a file generated by the maintainer scripts under the /etc directory.

For information on maintainer scripts, see Section 5.18, “{pre,post}{inst,rm}”.

Files listed in an install file don't need theirdirectories created first. See Section 5.11, “install”.

It is best to try to run the installation first and only use this if yourun into trouble. There is no preceding slash on the directory names listed inthe dirs file.

Download suara alarm darurat mobile banking. For more details on installing additional documentation, look in Section 3.3, “Installation of files to their destination”.

The package.init file isinstalled as the/etc/init.d/package scriptwhich starts and stops the daemon.Its fairly generic skeleton template is provided by thedh_make command as init.d.ex. You'lllikely have to rename and edit it, a lot, while making sure to provideLinux Standard Base (LSB) compliant headers. Itgets installed into the temporary directory by dh_installinit(1).

The package.default file willbe installed as/etc/default/package. Thisfile sets defaults that are sourced by the init script. Thispackage.default fileis most often used to disable running a daemon, or to set some default flags ortimeouts. If your init script has certain configurablefeatures, you can set them in the package.default file,instead of in the init script itself.

If your upstream program provides a file for the init script, you can either use it or not. If youdon't use their init script then create a new one inpackage.init. Howeverif the upstream init script looks fine and installs in the right place youstill need to set up the rc* symlinks. To do this you willneed to override dh_installinit in therules file with the following lines:

If you don't need this, remove the files.

If there are files that need to be installed into your package but yourstandard make install won't do it, put the filenames anddestinations into this install file. They are installedby dh_install(1).^[56] You should first check thatthere is not a more specific tool to use. For example, documents should be inthe docs file and not in this one.

This install file has one line per file installed, withthe name of the file (relative to the top build directory) then a space thenthe installation directory (relative to the install directory). One example of where this is used is if a binary src/bar is left uninstalled; theinstall file might look like:

This means when this package is installed, there will be an executable command/usr/bin/bar.

Alternatively, this install can have the name of the fileonly without the installation directory when the relative directory path doesnot change. This format is usually used for a large package that splits the output of its build into multiple binary packages usingpackage-1.install,package-2.install, etc.

The dh_install command will fall back to looking indebian/tmp for files, if it doesn't find them in thecurrent directory (or wherever you've told it to look using--sourcedir).

These postinst, preinst,postrm, and prerm files^[58] arecalled maintainer scripts. They are scripts which are putin the control area of the package and run by dpkg when yourpackage is installed, upgraded, or removed.

As a novice maintainer, you should avoid any manual editing ofmaintainer scripts because they are problematic. For moreinformation refer to the DebianPolicy Manual, 6 'Package maintainer scripts and installationprocedure', and take a look at the example files provided bydh_make.

If you did not listen to me and have created custom maintainerscripts for a package, you should make sure to test them not onlyfor install andupgrade but also forremove andpurge.

Upgrades to the new version should be silent and non-intrusive (existing usersshould not notice the upgrade except by discovering that old bugs have beenfixed and perhaps that there are new features).

When the upgrade is necessarily intrusive (eg., config files scattered throughvarious home directories with totally different structure), you mayconsider as the last resort switching the package to a safe fallback state(e.g., disabling a service) and providing the proper documentationrequired by policy (README.Debian andNEWS.Debian). Don't bother the user withdebconf notes invoked from these maintainer scriptsfor upgrades.

The ucf package provides aconffile-like handling infrastructure to preserve userchanges for files that may not be labeled as conffiles suchas those managed by the maintainer scripts. This shouldminimize issues associated with them.

These maintainer scripts are among the Debian enhancements thatexplain why people choose Debian. You mustbe very careful not to turn them into a source of annoyance.

Packaging of a library is not easy for a novice maintainer and should be avoided. Having said it, if your package has libraries, you should have debian/package.symbols files. See Section A.2, “Managing debian/package.symbols”.

The watch file format is documented in the uscan(1)manpage. The watch file configures theuscan program (in the devscripts package) to watch the site where youoriginally got the source. This is also used by theDebian Package Tracker service.

Here are its contents:

Normally with a watch file, the URL athttp://sf.net/gentoo is downloaded and searched for links ofthe form <a href=..>. The basename (just the partafter the final /) of each linked URL is compared againstthe Perl regular expression pattern (see perlre(1))gentoo-(.+).tar.gz. Out of the files that match, the one withthe greatest version number is downloaded and the uupdateprogram is run to create an updated source tree.

Although this is true for other sites, the SourceForge download service athttp://sf.net is an exception. When thewatch file has a URL matching the Perl regexp^http://sf.net/, the uscan programreplaces it with http://qa.debian.org/watch/sf.php/ andthen applies this rule. The URL redirector service at http://qa.debian.org/ is designed to offera stable redirect service to the desired file for anywatch pattern of the formhttp://sf.net/project/tar-name-(.+).tar.gz.This solves issues related to periodically changing SourceForge URLs.

If the upstream offers the cryptographic signature of the tarball, it isrecommended to verify its authenticity using thepgpsigurlmangle option as described in uscan(1).

The newer 3.0 (quilt) source format records modifications ina quilt patch series withindebian/patches. Those changes are then automaticallyapplied during extraction of the source package. ^[59] The Debian modifications are simply stored in adebian.tar.gz archive containing all files under thedebian directory. This new format supports inclusion ofbinary files such as PNG icons by the package maintainer without requiringtricks. ^[60]

When dpkg-source extracts a source package in 3.0(quilt) source format, it automatically applies all patches listed indebian/patches/series. You can avoid applying patches atthe end of the extraction with the --skip-patches option.

The autogenerated files in the source tree can be quite annoying for packagingsince they generate meaningless large patch files. There are custom modulessuch as dh_autoreconf to ease this problem as described in Section 4.4.3, “Customization of rules file”.

You can provide a Perl regular expression to the--extend-diff-ignore option argument of dpkg-source(1) to ignore changes made to the autogenerated files whilecreating the source package.

As a general solution to address this problem of the autogenerated files,you can store such a dpkg-source option argument in thesource/options file of the source package. The followingwill skip creating patch files for config.sub,config.guess, and Makefile.

The quilt command is explained in quilt(1).It records modifications to the source as a stack of -p1patch files in the debian/patches directory and the sourcetree is untouched outside of the debian directory. Theorder of these patches is recorded in thedebian/patches/series file. You can apply (=push),un-apply (=pop), and refresh patches easily. ^[62]

For Chapter 3, Modifying the source, we created three patches indebian/patches.

Since Debian patches are located in debian/patches, pleasemake sure to set up the dquilt command properly as describedin Section 3.1, “Setting up quilt”.

When anyone (including yourself) provides a patchfoo.patch to the source later,modifying a 3.0 (quilt) source package isquite simple:

The patches stored in the newer 3.0 (quilt) source formatmust be fuzz free. You can ensure this with dquiltpop -a; while dquilt push; do dquilt refresh; done.

^[54] In this chapter, files in the debian directory arereferred to without the leading debian/ for simplicity wheneverthe meaning is obvious.

^[55] See dpkg(1) andDebian Policy Manual, 'D.2.5 Conffiles'.

^[56] This replaces thedeprecated dh_movefiles(1) command which is configured by thefiles file.

^[57] Note that help2man'splaceholder man page will claim that more detailed documentation isavailable in the info system. If the command is missing aninfo page, youshould manually edit the man page created by thehelp2man command.

^[58] Despite this use of the bashshorthand expression {pre,post}{inst,rm} to indicate thesefilenames, you should use pure POSIX syntax for these maintainer scripts forcompatibility with dash as the system shell.

^[59] SeeDebSrc3.0 for a summary on the switch to the new 3.0(quilt) and 3.0 (native) source formats.

^[60] Actually, this new format also supports multipleupstream tarballs and more compression methods. These are beyond the scope ofthis document.

^[61] Several methods of patch set maintenance have been proposed and are in use for Debianpackages. The quilt system is the preferred maintenancesystem in use. Others include dpatch,dbs, and cdbs. Many of these keep suchpatches as debian/patches/* files.

^[62] If you areasking a sponsor to upload your package, this kind of clear separation anddocumentation of your changes is very important to expedite the package reviewby your sponsor.

SliTaz GNU/Linux is a lightweight Linux distribution, community-based, suitable for use on older hardware and as a Live CD or Live USB.^[4][5][6][7] SliTaz stands for 'Simple, Light, Incredible, Temporary Autonomous Zone' according to the boot screen.^[8]

• 3TazLiTo
  • 3.1Common Operations

Features[edit]

SliTaz uses the Openboxwindow manager.

Additional packages are added using a program called 'TazPanel'. This is due to the specific package format that SliTaz uses (tazpkg). It can still use packages from the more popular distribution though, as Debian, by means of first carrying out a conversion of these different packages.^[9]

Flexisign pro 8.1 free download with crack windows 10. WinRAR 5.80 Compress, Encrypt, Package and Backup with only one utilityOver 500 million users worldwide make WinRAR the world's most popular compression tool today.There is no better way to compress files for efficient and secure file transfer, faster e-mail transmission and well organized data storage.RAR and WinRAR are, available in over 50 languages in both 32bit and 64bit and several operating systems (OS) and the only compression software that is fully accepted in all countries using Unicode.

By default, SliTaz offers no persistence, however it can still be added if the user wish. The choice of the filesystem/bootloader used with slitaz is then of importance however; persistence being only available with ext2 and ext3 filesystems and the syslinux or extlinux boot loader.^[10][11]

Another useful tool is TazLiTo, with which users can create their own LiveCD based on selected packages or even based upon the current system state.

System requirements[edit]

SliTaz GNU/Linux is supported on all machines based on the i486 or x86 Intel compatible processors.^[12] The Live CD has four variants of SliTaz, requiring from 192 MB of RAM for the Core system to 48 MB for a text mode and X Window System.^[12]

SliTaz can even run in 16 MB of RAM and a little swap memory.^[13] SliTaz can be booted from a Live CD, Live USB, floppy disk, or a local area network (PXE^[14]),^[15] or can be installed, requiring approximately 80 MB of hard disk space.^[16]

TazLiTo[edit]

TazLito is the LiveCD creation utility in SliTaz GNU/Linux.

Common Operations[edit]

Check Root[edit]

Check to ensure UID is zero (i.e., TazLito was run by root or root sudoer).

Check Root File System[edit]

Looks for the existence of an etc. directory in the root file system directory. N.B., this does not do any further checking to ensure anything is actually in the directory. However, if TazLito is used for all LiveCD creation operations (that is, one does not create/modify the directories used by TazLito) the directories existence implies it is populated properly.

Verify Root CD[edit]

Looks for the existence of a boot directory in the root CD directory. N.B., this does not do any further checking to ensure anything is actually in the directory. However, if TazLito is used for all LiveCD creation operations (that is, one does not create/modify the directories used by TazLito) the directories existence implies it is populated properly.

Generate initramfs[edit]

1. Executes scripts for packages altering the root file system
2. Hard links redundant files in the root filesystem to save space
3. Runs cpio to create the initramfs, compressing with lzma or gzip (or no compression)

Release history[edit]

As with any Linux distribution, the route of development of SliTaz is mainly determined by the coders themselves. For SliTaz 5, some major changes seem to be the swapping of systemd by BusyBox's init and udev, hence avoiding safety risks, and more implementation of Qt.^[17] An implementation of x64 and ARM architectures are currently under development.

Reception[edit]

Dedoimedo reviewed SliTaz GNU/Linux 1.0. and commented:^[18]

Badgers are known for being rather spirited and fierce for their relatively small size. Slitaz follows suit. The first thing you'll notice is a simple boot menu, written in French. Even though I don't speak French, it was rather easily to understand what the author intended. That said, I do think 'neutral' distributions should go for English, as it is the most popular computer language around.

Dedoimedo also reviewed version 2.0.^[19]

DistroWatch wrote to DistroWatch Weekly a review of SliTaz GNU/Linux 1.0:^[20]

Now there is a new kid on the block. SliTaz GNU/Linux 1.0 is not just another small desktop distro; it is, in fact, the smallest by some margin and just half the size of Damn Small Linux. When it runs, the 25 MB compressed CD image expands to about 80 MB, so any computer with 128 MB of RAM will be able to load it fully into memory, ensuring blazing fast program execution. Computers with less memory can boot it too; with the boot prompt cheat code of 'slitaz-loram', computers with 64 MB of RAM are also supported, while those with as little as 16 MB of RAM will be able to run SliTaz as well - the cheat code is 'slitaz-loram-cdrom'. It goes without saying that the performance of the machine with 16 MB of RAM won't be nearly as good as that of the 128 MB one, but it's still hard to believe that there is an operating system that can run in graphical mode on machines with so little memory.

Gallery[edit]

• SliTaz 1.0 stable desktop.

• SliTaz 2.0 stable desktop.

• SliTaz 3.0 stable desktop.

• SliTaz 4.0 stable desktop.

• SliTaz 5.0 preview desktop.

See also[edit]

References[edit]

1. ^'SliTaz 1.0 Release Notes'. SliTaz. Retrieved 5 August 2012.
2. ^http://mirror1.slitaz.org/iso/rolling/
3. ^DistroWatch.com: SliTaz GNU/Linux
4. ^'SliTaz'. Linux Magazine. Retrieved 5 August 2012.
5. ^'Linux.com :: SliTaz, a mighty micro Linux distro'. Archive09.linux.com. Retrieved 2013-07-06.
6. ^Nick Veitch . '8 of the best tiny Linux distros: Slitaz and Tiny Core Linux News'. TechRadar. Retrieved 2013-07-06.CS1 maint: extra punctuation (link)
7. ^'Spotlight on Linux: SliTaz GNU/Linux 3.0'. Linux Journal. Retrieved 2013-07-06.
8. ^'A second look at Slitaz 1.0: turns out it has a lot of potential'. Click. 2008-06-26. Retrieved 2017-10-15.
9. ^Converting debian packages to tazpkg using convert command
10. ^Filesystem warning
11. ^[1]
12. ^ ^ab'SliTaz 4.0 Release Notes'. SliTaz. Retrieved 5 August 2012.
13. ^'Loram-CDrom'. Slitaz.
14. ^PXE with SliTaz
15. ^'From BIOS to /etc/init.d/rcS'. SliTaz Doc. Retrieved 5 August 2012.
16. ^'Introduction to the project'. SliTaz. Retrieved 5 August 2012.
17. ^Buildroot Slitaz post by coder
18. ^Slitaz Linux - Tiny but fierce, Dedoimedo
19. ^Slitaz 2 - 30MB of joy, Dedoimedo
20. ^First look at SliTaz GNU/Linux 1.0, the smallest desktop distro on earth, DistroWatch Weekly

External links[edit]

• SliTaz at DistroWatch