NiceOS RPM dist-git source for dos2unix
Find a file
NiceOS DistGit Import Bot 0dd614e615 Sync dos2unix from NiceOS Core snapshot
EVR: 7.5.3-1
Lock-SHA256: e76c4751c8a5e3a1d4887b0c6a3a6534aefb7fa6bff22bcbe8eb9e8827f817f7
Branch: niceos-5.2
2026-05-01 16:29:21 +03:00
METADATA Sync dos2unix from NiceOS Core snapshot 2026-04-27 21:45:58 +03:00
SBOM Sync dos2unix from NiceOS Core snapshot 2026-04-27 21:45:58 +03:00
SOURCES Sync dos2unix from NiceOS Core snapshot 2026-04-27 21:45:58 +03:00
SPECS Sync dos2unix from NiceOS Core snapshot 2026-04-27 21:45:58 +03:00
.gitignore Sync dos2unix from NiceOS Core snapshot 2026-04-27 21:45:58 +03:00
OWNERS Sync dos2unix from NiceOS Core snapshot 2026-04-27 21:45:58 +03:00
README.md Sync dos2unix from NiceOS Core snapshot 2026-05-01 16:29:21 +03:00
README_RU.md Sync dos2unix from NiceOS Core snapshot 2026-05-01 16:29:21 +03:00

dos2unix

Overview

dos2unix is a small text conversion utility for changing line endings between DOS/Windows style and Unix style text files. The upstream project also provides the related unix2dos utility for the reverse conversion. In practice, this package is useful whenever text files move between Windows-oriented and Unix-oriented environments and line ending normalization is needed.

For a Linux distribution, packaging dos2unix is mainly about providing a reliable command-line tool that users and build systems can call directly, rather than expecting each project to implement its own line-ending handling. NiceOS maintainers should still verify packaging details against the upstream documentation before each update.

Purpose and typical use cases

Typical use cases include:

  • converting text files imported from Windows systems so they behave correctly in Unix tools;
  • normalizing scripts, configuration files, and documentation files before committing them to a repository;
  • fixing line endings in build inputs or generated files during packaging and CI work;
  • checking or converting files as part of release engineering workflows;
  • using unix2dos when files must be delivered to a Windows-oriented environment.

Typical users are:

  • system administrators;
  • developers and build engineers;
  • CI/CD maintainers;
  • package maintainers;
  • users who regularly exchange text files between different operating systems.

Upstream project

The upstream project is the dos2unix text file format converter from Waterlan. The project site describes dos2unix and unix2dos as tools for converting plain text files between DOS or Mac line breaks and Unix line breaks, with additional documentation and manual pages on the upstream site. (waterlan.home.xs4all.nl)

Upstream documentation is the best place to confirm behavior, command-line options, and build expectations before changing the package. If NiceOS packaging diverges from upstream defaults, maintainers should document that explicitly in the spec or changelog.

Dist-git repository contents

This dist-git repository is organized as follows:

  • SPECS/ — RPM spec files and packaging logic.
  • SOURCES/ — source metadata and manifest files used to track upstream inputs.
  • METADATA/ — repository metadata used by the packaging workflow.
  • SBOM/ — software bill of materials material, when present in the repository workflow.

Large upstream source archives are intentionally not stored in this Git repository. Instead, the repository keeps integrity metadata in SOURCES manifests, so the source set can be verified without committing the full upstream tarball history into Git.

Source storage and integrity policy

The source policy for this package is to keep large upstream source archives outside the Git repository while storing source integrity information in manifest files under SOURCES.

For maintainers, that means the important checks are:

  • confirm the manifest still points to the intended upstream source set;
  • verify that the source contents match what upstream published;
  • review whether any packaging-side generated files need to be refreshed;
  • avoid relying on repository state alone when validating a source update.

Do not assume that a source update is safe just because the manifest format did not change. Check the upstream documentation and package metadata together.

NiceOS maintenance notes

Before updating this package, NiceOS maintainers should check:

  • whether upstream behavior or command-line options changed;
  • whether the upstream manual or documentation was updated and needs to be reflected in packaging notes;
  • whether any patches, translations, or documentation files in the package tree need regeneration;
  • whether tests or build scripts depend on line-ending-sensitive fixtures;
  • whether changes to default behavior could affect script processing in downstream builds.

Possible update risks include:

  • accidental changes in text normalization behavior;
  • regressions in packaging tests that use mixed line endings;
  • documentation drift between the spec file and upstream manuals;
  • stale generated files that should be refreshed after source updates.

If a detail is unclear, NiceOS maintainers should verify it against upstream before relying on it.

Build and verification checklist

A practical RPM maintainer checklist for this package:

  • review the upstream release notes and manual for changed behavior;
  • confirm the source manifest in SOURCES matches the intended upstream inputs;
  • inspect the spec file for any patches or build-time assumptions;
  • rebuild the package in a clean environment;
  • run the package test suite if the spec enables one;
  • verify the installed binaries and manual pages are present;
  • check that the conversion utilities behave as expected on representative sample files;
  • confirm no generated packaging files need regeneration;
  • review the resulting RPM metadata for unexpected dependency or file-list changes.

References

Russian documentation

See README_RU.md for the Russian version of this documentation.

Dist-git repository notes

  • Package repository: rpms/dos2unix
  • NiceOS branch: niceos-5.2
  • This README is intentionally stable and does not include EVR, source archive checksums or lock hashes.