Giter Site home page Giter Site logo

repology / repology-rules Goto Github PK

View Code? Open in Web Editor NEW
102.0 102.0 117.0 12.04 MB

Package normalization ruleset for Repology

Home Page: https://repology.org

License: GNU General Public License v3.0

Python 98.10% Makefile 1.13% Shell 0.77%
package packages repository version

repology-rules's Introduction

Repology

CI codecov

Repology is a service which monitors a lot of package repositories and other sources and aggregates data on software package versions, reporting new releases and packaging problems.

This repository contains Repology updater code, a backend service which updates the repository information. See also the web application code.

Dependencies

Needed for fetching/parsing repository data:

Development dependencies

Optional, for doing HTML validation when running tests:

Optional, for checking schemas of configuration files:

Optional, for python code linting:

Running

Preparing

Since repology rules live in separate repository you'll need to clone it first. The location may be arbitrary, but rules.d subdirectory is what default configuration file points to, so using it is the most simple way.

git clone https://github.com/repology/repology-rules.git rules.d

Configuration

First, you may need to tune settings which are shared by all repology utilities, such as directory for storing downloaded repository state or DSN (string which specifies how to connect to PostgreSQL database). See repology.conf.default for default values, create repology.conf in the same directory to override them (don't edit repology.conf.default!) or specify path to alternative config via REPOLOGY_SETTINGS environment variable, or override settings via command line.

By default, repology uses ./_state directory for storing raw and parsed repository data and repology/repology/repology database/user/password on localhost.

Creating the database

For the following steps you'll need to set up the database. Ensure PostgreSQL server is up and running, and execute the following commands to create the database for repology:

psql --username postgres -c "CREATE DATABASE repology"
psql --username postgres -c "CREATE USER repology WITH PASSWORD 'repology'"
psql --username postgres -c "GRANT ALL ON DATABASE repology TO repology"
psql --username postgres --dbname repology -c "GRANT CREATE ON SCHEMA public TO PUBLIC"
psql --username postgres --dbname repology -c "CREATE EXTENSION pg_trgm"
psql --username postgres --dbname repology -c "CREATE EXTENSION libversion"

in the case you want to change the credentials, don't forget to add the actual ones to repology.conf.

Populating the database

Note that you need more than 11GiB of disk space for Repology PostgreSQL database and additionally more than 11GiB space for raw and parsed repository data if you decide to run a complete update process.

Option 1: use dump

The fastest and most simple way to fill the database would be to use a database dump of main Repology instance:

curl -s https://dumps.repology.org/repology-database-dump-latest.sql.zst | unzstd | psql -U repology

Option 2: complete update

Another option would be to go through complete update process which includes fetching and parsing all repository data from scratch and pushing it to the database.

First, init the database schema:

./repology-update.py --initdb

Note that this command drops all existing data in Repology database, if any. You only need to run this command once.

Next, run the update process:

./repology-update.py --fetch --fetch --parse --database --postupdate

Expect it to take several hours the first time, subsequent updates will be faster. You can use the same command to updated. Brief explanation of options used here:

  • --fetch tells the utility to fetch raw repository data (download files, scrape websites, clone git repos) into state directory. Note that it needs to be specified twice to allow updating.
  • --parse enables parsing downloaded data into internal format which is also saved into state directory.
  • --database pushes processed package data into the database.
  • --postupdate runs optional cleanup tasks.

Documentation

Author

License

GPLv3 or later, see COPYING.

repology-rules's People

Contributors

alerque avatar amdmi3 avatar awilfox avatar chemrat avatar chocimier avatar city-busz avatar epsilon-0 avatar fabiololix avatar ikke avatar jbicha avatar jcgruenhage avatar jon-turney avatar jrmarino avatar klemensn avatar kpcyrd avatar l2dy avatar luflosi avatar luzpaz avatar ooliver1 avatar oxzi avatar pink-mist avatar ryantm avatar s0600204 avatar sgn avatar simon04 avatar sternenseemann avatar trenly avatar veprbl avatar waldyrious avatar whissi avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

repology-rules's Issues

Provide disambiguated name in all/most cases

Currently it's common to set a disambiguated name for a less wide spread project, and leave wider spread project with a short name. It seems useful though to set disambiguated names in all cases.

MinGW packages

From repology/repology-updater#248 by @mojca:

The MinGW packages are currently a bit of a mess, with each distribution providing its own package names.

There are two "different" projects, MinGW and MinGW-w64. And package are different:

  • the compiler (gcc) which should be at some fixed version of gcc (compared to gcc versions)
  • binutils (which should be compared to binutils versions)
  • mingw-w64 itself
  • potentially other libraries for use when cross-compiling

In case of MacPorts we have five packages that derive from mingw-w64 for example:

  • mingw-w64 @5.0.2 (meta port)
  • i686-w64-mingw32-crt @5.0.2
  • i686-w64-mingw32-headers @5.0.2
  • x86_64-w64-mingw32-crt @5.0.2
  • x86_64-w64-mingw32-headers @5.0.2

plus binutils, gcc, ... as well as the old MinGW package.

pmw 4.240 version should be seen as 4.24.0

subject says it all.

The pmw upstream maintainer once uploaded a version number "4.231" when he had made a slight mistake in the 4.23 release, and wanted to add a minor update. He saw "4.23" as a fractional number, so "4.231" is less than 4.24 in that case.

However, that's not how version numbers work generally, and Rosa then updated 4.24 to become '4.240' rather than '4.24.0' or some such.

Might be good to ignore that inconsistency.

Use more informative rule classification

Supersedes #2. ignore should not be used in general case, replace it with incorrect or snapshot as applicable.

  • 0
  • a
  • b
  • c
  • d
  • e
  • f
  • g
  • h
  • i
  • j
  • k
  • l
  • lib
  • m
  • n
  • o
  • p
  • perl
  • python
  • q
  • r
  • s
  • t
  • u
  • v
  • w
  • x
  • y
  • z

CFlow naming conflict

As seen on Repology's cflow page, FreeBSD and DPorts ship "2.0" while the rest have 1.4/1.5.

All 1.x versions correspond to GNU CFlow. FreeBSD's cflow-2.0 was released in 1995, about 10 years before GNU's existed.

The problem is I don't know what the FreeBSD CFlow package's proper name would be. It isn't bsdcflow, as that already exists.

comparison of forks of packages

there is at least one fork of openssl (openssl-1.0-chacha) which should be treated as an independent package:
https://repology.org/metapackage/openssl/versions
I have tried to request for a unique name (PeterMosmans/openssl#51) but it has yet to be decided.

There is also a more complex example:
https://repology.org/metapackage/rtl8812au/versions
repology threats it as one package, however there are multiple forks of it:
rtl8812au https://github.com/abperiasamy/rtl8812AU_8821AU_linux
rtl8812au_astsam https://github.com/astsam/rtl8812au
rtl8812au_asus https://github.com/codeworkx/rtl8812au_asus/commits/master
rtl8812au_aircrack-ng https://github.com/aircrack-ng/rtl8812au

The last one is most active and provides patches for hacking which can't be merged back to the upstream. The official version is 5.1.5~20180506 (aircrack-ng/rtl8812au@db3e2fa) but it is not recognised correctely.

FLTK versions

Repology currently shows FLTK version 2.0 as current and 1.x versions as outdated. This is incorrect.

FLTK has quite a history in being rather strange when it comes to versioning. Version 1.1.x superseded 1.0.x which is completely obsolete today. 1.1.10 was the last version of the 1.1.x branch and could be added as a legacy package (while it's officially unsupported, there's still quite a bit of software that uses it and as far as I know some developers for small or embedded devices prefer it over newer versions because it's so extremely light-weight).

Then 2.0 was started - but despite being highly anticipated by many it simply never happened. A developer once told me that it felt like that version was cursed. While an attempt to revive it was made later, there has never been an official release. Alpha versions were available, but that's it. According to Repology, PCLinuxOS offers FLTK 2.0.0. That's definitely wrong and most likely is an alpha release with an incurrect version number. A non-alpha 2.x FLTK version should be reported as a problem instead of a current package.

The 1.2 branch is irrelevant. For the 1.3 some features (like unicode support) of the never arrived 2.0 were ported back to the 1.10 API. Development has stopped but it is considered the stable branch with 1.3.4-2 being the most recent official release of FLTK.

3.x was an attempt to escape the rather poor versioning situation by taking 1.3 as a base and re-implementing the more modern API of 2.0 on it. This effort has unfortunately stalled.

Currently development is active on the 1.4 branch but it has not seen any release, yet.

KDE development branches

Odd minor version should be marked as devel. See


  • akonadi
  • akonadi-calendar
  • akonadi-calendar-tools
  • akonadi-contacts
  • akonadi-import-wizard
  • akonadi-mime
  • akonadi-notes
  • akonadi-search
  • akonadiconsole
  • akregator
  • analitza
  • ark
  • artikulate
  • audiocd-kio
  • baloo-widgets
  • blinken
  • bovo
  • calendarsupport
  • cantor
  • cervisia
  • dolphin
  • dolphin-plugins
  • dragon-player
  • eventviews
  • ffmpegthumbs
  • filelight
  • granatier
  • grantlee-editor
  • grantleetheme
  • gwenview
  • incidenceeditor
  • juk
  • k3b
  • kaccounts-integration
  • kaccounts-providers
  • kaddressbook
  • kalarm
  • kalarmcal
  • kalgebra
  • kalzium
  • kanagram
  • kapptemplate
  • kate
  • kbounce
  • kbruch
  • kcachegrind
  • kcalc
  • kcalcore
  • kcalutils
  • kcharselect
  • kcolorchooser
  • kcontacts
  • kcron
  • kdav
  • kde-common (no such thing)
  • kdebugsettings
  • kdeedu-data
  • kdegraphics-mobipocket
  • kdegraphics-thumbnailers
  • kdenetwork-filesharing
  • kdenlive
  • kdepim-addons
  • kdepim-apps-libs
  • kdepim-runtime
  • kdesdk-kioslaves
  • kdesdk-thumbnailers
  • kdialog
  • keditbookmarks
  • kfind
  • kfourinline
  • kgeography
  • kget
  • kgpg
  • khangman
  • khelpcenter
  • kidentitymanagement
  • kig
  • kimap
  • kio-extras
  • kiriki
  • kiten
  • kldap
  • kleopatra
  • klettres
  • kmag
  • kmahjongg
  • kmail
  • kmail-account-wizard
  • kmailtransport
  • kmbox
  • kmime
  • kmines
  • kmix
  • kmouth
  • kmplot
  • knavalbattle
  • knotes
  • kolourpaint
  • kompare
  • konqueror
  • konquest
  • konsole
  • kontact
  • kontactinterface
  • kopete
  • korganizer
  • kpat
  • kpimtextedit
  • krdc
  • krfb
  • kruler
  • kshisen
  • ksmtp
  • ksystemlog
  • kteatime
  • ktimer
  • ktnef
  • ktouch
  • ktuberling
  • kturtle
  • kwalletmanager
  • kwave
  • kwordquiz
  • libgravatar
  • libkcddb
  • libkdcraw
  • libkdegames
  • libkdepim
  • libkeduvocdocument
  • libkexiv2
  • libkgapi
  • libkipi
  • libkleo
  • libkmahjongg
  • libkomparediff2
  • libksane
  • libksieve
  • lokalize
  • mailcommon
  • mailimporter
  • marble
  • messagelib
  • okular
  • parley
  • pimcommon
  • print-manager
  • rocs
  • signon-kwallet-extension
  • spectacle
  • step
  • sweeper
  • umbrello

Gentoo needs more package splits

Need to be split:

  • btf (dev-java and sci-libs)

Actually, a lot more:

find gentoo.git -type d -maxdepth 2 -mindepth 2 |
   egrep -v 'dev-(perl|python|haskell)' |
   awk -F/ '{print $NF}' |
   sort | uniq -d
  • ace
  • acl
  • ada
  • amap
  • analog
  • apel
  • atlas
  • attica
  • auctex
  • baloo
  • balsa
  • barcode
  • bbdb
  • bfm
  • binclock
  • bluedevil
  • bson
  • btf
  • build
  • c-support
  • calc
  • calendar
  • cdcover
  • cdrtools
  • charm
  • checkpassword
  • coffee-script
  • color
  • crystal
  • csv
  • daemontools
  • dash
  • dictionary
  • dirdiff
  • docker
  • dolphin
  • ebuild-mode
  • ecb
  • eject
  • elib
  • emacs
  • ess
  • exo
  • fam
  • fcgi
  • ffmpeg
  • fuse
  • gambit
  • gdl
  • git
  • glade
  • glu
  • gnupg
  • gnuplot
  • gom
  • gpgme
  • grip
  • gsasl
  • haskell-mode
  • highline
  • icecream
  • igrep
  • info
  • jack
  • jal
  • jama
  • jde
  • jpeg
  • json
  • kactivities
  • kde-gtk-config
  • kdeplasma-addons
  • kdesu
  • kfilemetadata
  • kglobalaccel
  • khotkeys
  • kinfocenter
  • kmenuedit
  • knewstuff
  • krunner
  • kscreen
  • kstart
  • ksysguard
  • kwin
  • kwrited
  • languagetool
  • launchy
  • lemon
  • libelf
  • libffi
  • libgudev
  • libiconv
  • libintl
  • libkscreen
  • libnet
  • libusb
  • locale
  • lookup
  • lzma
  • magic
  • mailcrypt
  • mailx
  • man
  • mars
  • mash
  • mavros
  • mc
  • mediawiki
  • mew
  • milou
  • mime-types
  • mldonkey
  • mmix
  • mmm-mode
  • modutils
  • mongo
  • mpack
  • mpc
  • msgpack
  • muse
  • mysql
  • nagios
  • nemesis
  • ninja
  • nitrogen
  • notification-daemon
  • nut
  • ocaml
  • openmsx
  • otter
  • pam
  • par
  • pcl
  • pdv
  • picard
  • pkgconfig
  • planner
  • plasma-mediacenter
  • plasma-nm
  • plasma-workspace
  • pmake
  • pms
  • polkit-kde-agent
  • polyglot
  • powerdevil
  • psgml
  • psi
  • python-mode
  • rails
  • re2
  • redis
  • reduce
  • riece
  • ruby
  • rubygems
  • screen
  • session
  • shadow
  • signify
  • silo
  • ski
  • skkserv
  • slim
  • slurm
  • smack
  • sml-mode
  • snappy
  • spice
  • spin
  • splat
  • splice
  • sqlite3
  • ssh
  • surf
  • systemsettings
  • szip
  • teco
  • texinfo
  • tf
  • time
  • tokyocabinet
  • tornado
  • tree
  • uclibc
  • udev
  • vc
  • vm
  • w3m
  • xclip
  • xslide
  • xsp
  • yacc
  • zenburn
  • zenirc

Replace underscores early

Currently _ are replaced at the very end of the ruleset. There's no real reason for this, we can do it in 000 and simplify the rest of the rules.

freebsd/dports systematic hunspell mismatch (rules needed)

From repology/repology-updater#358 by @jrmarino:

FreeBSD Ports has two styles for hunspell naming:

  1. XX-hunspell (where XX is a language code)
  2. [language]/hunspell (e.g. polish/hunspell)

The hunspell ports of type 1 show as "unique" ports (e.g. https://repology.org/metapackages/in-repo/dports/?search=hunspell). There should be a rule to transform XX-hunspell to "hunspell-XX" to match existing packages.

The hunspell ports of type 2 don't seem to show at all. They would need individual rules I guess (e.g. english, german, french, polish, vietnamese, etc, etc).

I thought the same case would exist for aspell, but that seems okay. (https://repology.org/metapackages/in-repo/dports/?search=aspell)

Use custom format for rules

YAML sucks here. Need a custom format:

  • one rule per line; parser should save line numbers to reference them later
  • comments as usual
  • no quotes
  • lists separated by commas, fields separated by whitespace
  • merge name/namepat; we can guess whether this is a pattern by looking for special characters (non-pattern is roughly ^[a-zA-Z0-9_:-]+$)

Examples:

name=sidplay[0-9]+                 setname=sidplay
name=softshm       verpat=1\..*    setname=softshm1
name=geos1,geos35                  setname=geos
family=gentoo category=dev-haskell setname=haskell:$0

MATE development branches

There are already some metapackages that simultaneously have both stable and development branches for which the choice is based only on the version number:

  • darktable: 2.4.* is stable, 2.5.* is development
  • libreoffice: 6.0.* is stable, 6.1.* is development
  • and so on

It would be very great if this behavior will also be propagated to the packages of the MATE project: even versions are stable (currently 1.20) while odd - are development (currently 1.21). Here MATE blog with release announcements.

Affected packages:

FreeBSD's gYYYYMMDD and others YYYYMMDD should be compared as dates

For example, the 'castxml' package demonstrates the problem.

In FreeBSD, if the version begins from 'g', this means that the version if ad-hoc, and uncomparable. But a lot of packages use gYYYYMMDD format, which represents dates. On the other hand, other systems often use YYYYMMDD format. In case of gYYYYMMDD, you should remove 'g' from the FreeBSD version and allow it to be compared as YYYYMMDD. This way, at least, there is a chance that comparison would be meaningful. With 'g' - there is no such chance, because 'g' is FreeBSD-specific.

Merge all prefixed libraries

lib32-libfoo, mingw-w64-libfoo and alike are the same libfoo essentially, so add some early rules to remove these prefixes.

Normalize libretro projects

There are a lot of noscheme requests in reports for these, there's a bunch of scattered rules, however this needs to be sorted out and completed. I think we should use libretro:* naming for these, as there's a discrepancy of libretro-foo and foo-libretro.

Mark all rules that require maintainance

Devel versions of, for example, less or tor cannot be identified by version pattern solely, so corresponding rules need to be kept up to date. To simplify this, need to mark them all with XXX: MAINTAINANCE comment

Normalize emacs plugins

May probably use wildcard rules for e.g. *.el names and app-emacs gentoo category. *-emacs are more tricky and may produce false positives. Need investigation.

Ignore all dates in versions, with a whitelist

We already have more than 250 ignore rules for version patterns of 20[0-9]{6} and alike (e.g. dates). It seems viable to instead identify projects that DO officially use dates in versions, make a whitelist for them and ignore all other dates globally.

The whitelist maintenance cost involve considerable amount of work at start to identify and review all legal cases, after which the upkeep would be easier (basically, only processing new entries infrequently). This should/could overweight the constant cost of processing reports of fake date versions and user annoyance.

NB:

  • Total metapackages with 20[0-9]{6}: 12126
  • Total metapackages with 20[0-9]{6}$: 9717
  • Total metapackages with '^20[0-9]{6}$: 5819

This is the upper estimate of work required. We can start with the narrower pattern. Actual cost would be smaller, as we only need to review non-unique metapackages and exclude e.g. rolling versions. Also the most of these are texlive-* metapackages. In most conservative case, only couple hundreds of metapackages need to be reviewed.

Rules for MinGW on MacPorts

From repology/repology-updater#383 by @mojca:

The MinGW packages for MacPorts are split in a weird way. There's mingw-w64 which is some kind of a meta-package and is at the same version as *-w64-mingw32-crt, *-w64-mingw32-headers (and soon *-w64-mingw32-winpthreads).

Then *-w64-mingw32-gcc is basically gcc cross-compiler. And *-w64-mingw32-binutils is basically binutils for cross-compiler. I don't know against which packages these are supposed to be compared and I'm not sure how to write the rules for such a split, but it would be nice to correct this.

(Plus there's a bunch of abandonware i386-mingw32-*.)

Refactor the ruleset

Considerations:

  • don't try to classify rules by topic. It takes extra effort, doesn't always lead to clean classification and lead to rules belonging to a single entity spread in a lot of places in the ruleset (merges, verfixes, ambiguities, ver splits, modules, repository and global bits)
  • rule dependencies should be avoided. E.g. split rule should not precede verfix, which should be duplicated for each split result.

Main idea of suggested order is that merges and renames come first, followed by ambiguity splits, followed by version fixes, followed by version splits.

forgotten reports?

Several reports haven't been answered:

perl:exporter-tiny (16 days old)
perl:io-tty (16 days old)
perl:xml-namespacesupport (16 days old)
python:enum (16 days old)

I don't know if there was a huge long queue and they are stilll in line, but it seems more likely that they've been overlooked.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.