debian popcon manche Pakete nicht gelistet

[Marco Moock]

Hallo zusammen,
was ist der Grund, dass bei Debian popcon nicht alle Pakete gelistet
werden, die das main-Repo beinhaltet?

Beispiel:
https://qa.debian.org/popcon.php?package=fingerd
https://packages.debian.org/search?suite=all&searchon=names&keywords=fingerd

--
Gruß
Marco

[Jens Schüßler]

* Marco Moock <mo...@posteo.de> [26-09-22 13:33]:

Weil popcon nur mit den Namen von source-packages funktioniert (frag
mich aber nicht warum das so ist)
https://qa.debian.org/popcon.php?package=bsd-finger

[Marco Moock]

Am 26.09.2022 um 16:16:59 Uhr schrieb Jens Schüßler:

> Weil popcon nur mit den Namen von source-packages funktioniert (frag
> mich aber nicht warum das so ist)

Danke für die Info.
Was ist da der genaue Unterschied zu normalen Paketen?

[Jens Schüßler]

* Marco Moock <mo...@posteo.de> [26-09-22 14:24]:

Um die Frage zu beantworten ist sicher Marc Haber besser geeignet.

Ich weiß es wie gesagt nicht und habe das nur entdeckt indem ich auf
https://packages.debian.org/en/bullseye/fingerd "Developer Information"
aufgerufen habe und dort ist unter 'links' ein Link zu 'popcon'.
Die 'Developer Information' verweist im Übrigen auch schon auf dem Namen
des Quellpakets
https://tracker.debian.org/pkg/bsd-finger

[Kay Martinen]

Am 26.09.22 um 16:24 schrieb Marco Moock:

> Am 26.09.2022 um 16:16:59 Uhr schrieb Jens Schüßler:
>
>> Weil popcon nur mit den Namen von source-packages funktioniert (frag
>> mich aber nicht warum das so ist)

Dann dürfte aber auf https://popcon.debian.org/ unter "Statistics for
sections sorted by fields" auch main nicht vorhanden oder leer sein. :)

Oder das ist es nicht weil es für jedes dort gelistete paket ein
source-paket gibt aus dem man das binary selbst bauen könnte - wenn man
das wollte. Debian steht doch für Freie Software = Quellcode verfügbar
== Source-pakete

> Danke für die Info.
> Was ist da der genaue Unterschied zu normalen Paketen?
>

Ich vermute da einen Zusammenhang mit den Paketquellen. Z.b. mit den
optionalen die nicht-freien code (non-free) enthalten können. Für die
wird es sicher kaum source-pakete geben oder?

Bedenkt man obiges dürfte popcon nur für <beliebiges Paket>
funktionieren wenn es neben <arch>paketname auch ein <src>paketname gibt.

Bei einer Distro wie Debian die wert auf Freien Code legt kann es m.E.
überhaupt nicht anders sein.

N.B. Source-repos muß man m.W. getrennt aktivieren. Dafür gibt es
'deb-src' in der sources.list

Ｂｙｅ／
／Ｋａｙ

--
"Kann ein Wurstbrot die Welt retten?" :-)

[Marc Haber]

Jens Schüßler <j.sc...@nurfuerspam.de> wrote:
>* Marco Moock <mo...@posteo.de> [26-09-22 14:24]:
>> Am 26.09.2022 um 16:16:59 Uhr schrieb Jens Schüßler:
>>
>>> Weil popcon nur mit den Namen von source-packages funktioniert (frag
>>> mich aber nicht warum das so ist)
>>
>> Danke für die Info.
>> Was ist da der genaue Unterschied zu normalen Paketen?
>>
>
>Um die Frage zu beantworten ist sicher Marc Haber besser geeignet.

Upstream liefert Upstream-Sourcen (z.B. sudo)
Der Debian-Maintainer macht daraus ein Debian-Source-Paket (hier,
bestehend aus sudo.orig.tar.gz, sudo.debian.tar.gz und sudo.dsc)
Der Buildd macht aus dem Sourcepaket Binärpakete (hier: sudo.deb und
sudo-ldap.deb)
Der Anwender installiert die Binärpakete.

Dabei können aus einem Source-Paket mehrere Binärpakete rausfallen,
und das Source-Paket kann ganz anders heißen als das Binärpaket (z.B.
bsd-finger oder auch netcat-traditional).

Die meisten Entwicklertools operieren auf dem Raum der
Source-Packages, weil das die Einheit ist, die man als Maintainer
anfasst (z.B. tracker.debian.org und popcon).

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Peter J. Holzer]

Source-Packages enthalten - wie der Name schon sagt - Source-Code. Aus
einem Source-Packge entstehen ein oder mehr Binary-Packages.

hp

[Marc Haber]

Wobei es - um die Verwirrung komplett zu machen - auch "binary"
packages gibt, die Source-Code für Kernelmodule enthalten.

Vielleicht sollten wir (=Debian) besser von "buildable Packages" und
"installable Packages" reden.

[Peter J. Holzer]

On 2022-09-26 18:31, Marc Haber <mh+usene...@zugschl.us> wrote:
> "Peter J. Holzer" <hjp-u...@hjp.at> wrote:
>>On 2022-09-26 14:24, Marco Moock <mo...@posteo.de> wrote:
>>> Am 26.09.2022 um 16:16:59 Uhr schrieb Jens Schüßler:
>>>> Weil popcon nur mit den Namen von source-packages funktioniert (frag
>>>> mich aber nicht warum das so ist)
>>>
>>> Danke für die Info.
>>> Was ist da der genaue Unterschied zu normalen Paketen?
>>
>>Source-Packages enthalten - wie der Name schon sagt - Source-Code. Aus
>>einem Source-Packge entstehen ein oder mehr Binary-Packages.
>
> Wobei es - um die Verwirrung komplett zu machen - auch "binary"
> packages gibt, die Source-Code für Kernelmodule enthalten.

Ja, meine "binary" Packages enthalten üblicherweise auch keine Binarys,
sondern Python- oder Perl-Scripts bzw. -Module. Ich habe sogar schon
welche gebaut, die nur ein Konfigurationsfile enthalten.

> Vielleicht sollten wir (=Debian) besser von "buildable Packages" und
> "installable Packages" reden.

Wäre eindeutiger, ja. Hat sich aber halt so eingebürgert.

hp

[Kay Martinen]

Am 26.09.22 um 20:31 schrieb Marc Haber:

> "Peter J. Holzer" <hjp-u...@hjp.at> wrote:
>> On 2022-09-26 14:24, Marco Moock <mo...@posteo.de> wrote:
>>> Am 26.09.2022 um 16:16:59 Uhr schrieb Jens Schüßler:
>>>> Weil popcon nur mit den Namen von source-packages funktioniert (frag
>>>> mich aber nicht warum das so ist)
>>>
>>> Danke für die Info.
>>> Was ist da der genaue Unterschied zu normalen Paketen?
>>
>> Source-Packages enthalten - wie der Name schon sagt - Source-Code. Aus
>> einem Source-Packge entstehen ein oder mehr Binary-Packages.
>
> Wobei es - um die Verwirrung komplett zu machen - auch "binary"
> packages gibt, die Source-Code für Kernelmodule enthalten.

Wäre so ein "Kandidat" etwa ein dkms-paket, z.B. für Virtualbox... So
weit ich das sehe/verstehe stecken da nur die
kernelversions-spezifischen quellkodes der virtualbox treiber drin die
dann auf dem system gebaut werden - durch dkms.

Vielleicht sind es ha auch nur die treiberquellcodes mit
kernel-spezifischen patches oder build-anweisungen oder sonst was. Das
hat mich bisher nie so weit interessiert das ich da rein schaute. Nach
einem neuen kernel oder dem entfernen eines alten sehe ich nur was von
dkms und das da was gebaut oder entfernt wird. Bisher immer erfolgreich.
Was mich bei stable jetzt auch nicht viel wundert.

Allerdings ist das hier ein Ubuntu, das ich hierbei einfach mal frech
mit debian in einen Topf werfe.

> Vielleicht sollten wir (=Debian) besser von "buildable Packages" und
> "installable Packages" reden.

Warum eigentlich nicht "executable" was sowohl binary als auch shell
o.a. scripte mit einschließt.

Denn "installable" kann z.b. auch eine alias.db sein, ausgeführt wird
sie aber dennoch nicht. Ich will jetzt nicht auch noch den typ
"dateable" :) vorschlagen, das ginge mir auch zu weit.

Aber "installable" ist quellcode ja irgendwie auch - nur nicht direkt
verwendbar. dpkg/apt als "installer" annehmend was es ja prinzipiell
auch ist.

Mangels besserer Ideen, diskutieren wir's?

[Christian Garbs]

Mahlzeit!

Kay Martinen <use...@martinen.de> wrote:
> Am 26.09.22 um 20:31 schrieb Marc Haber:

>> Vielleicht sollten wir (=Debian) besser von "buildable Packages" und
>> "installable Packages" reden.
>
> Warum eigentlich nicht "executable" was sowohl binary als auch shell
> o.a. scripte mit einschließt.

Weil das auch nicht passt: Das Paket 'wesnoth-music' enthält weder
Shellcode noch Executables, sondern Musik. Es ist aber ein 'binary
package' (also etwas, das gebaut und installierbar verpackt wurde),
weil es (zusammen mit anderen 'binary packages') aus dem
Source-Package 'wesnoth' gebaut wurde.

> Denn "installable" kann z.b. auch eine alias.db sein, ausgeführt wird
> sie aber dennoch nicht. Ich will jetzt nicht auch noch den typ
> "dateable" :) vorschlagen, das ginge mir auch zu weit.

Die Unterscheidung 'buildable' (da läuft ein Debian-Buildprozess
drüber) und 'installable' (das kann man sich als Endnutzer
installieren) finde ich auch sprechender als die aktuelle Wortwahl,
ich würde das sofort so unterstützen, falls jemand fragt ;-)


Oder nochmal andersherum:

* binary ('installable') packages kommen aus 'deb'-Zeilen in der
/etc/apt/sources.list. Die braucht jeder, damit er sich ein System
zusammeninstallieren kann. Und ist ist vollkommen egal, ob in
diesen Paketen Binaries, Bilder, Musik, Manpages oder Sourcecode
enthalten sind.

* source ('buildable') packages kommen aus den 'deb-src'-zeilen in
der /etc/apt/sources.list. Die braucht man nur, wenn man an den
Paketsourcen herumschraubt und eigene Pakete baut. Auch da kann
potenziell alles in dem Paket enthalten sein, meist ist es halt ein
Upstream-Release mit Sourcecode plus Paketierungsinformationen.

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
"How many Centauri does it take to, um, screw in a light bulb? -- Just
one. But, in the great old days of the Republic, hundreds of servants
would change a thousand lightbulbs at our slightest whim." (Londo)

[Marc Haber]

Erschwerend kommt die Negation hinzu, wenn ein Paket "unbuildable"
oder "uninstallable" ist dann ist es kaputt.

[Marc Haber]

Kay Martinen <use...@martinen.de> wrote:
>Am 26.09.22 um 20:31 schrieb Marc Haber:

>> Wobei es - um die Verwirrung komplett zu machen - auch "binary"
>> packages gibt, die Source-Code für Kernelmodule enthalten.
>
>Wäre so ein "Kandidat" etwa ein dkms-paket, z.B. für Virtualbox... So
>weit ich das sehe/verstehe stecken da nur die
>kernelversions-spezifischen quellkodes der virtualbox treiber drin die
>dann auf dem system gebaut werden - durch dkms.

Genau, das ist der Fall den ich da oben meinte.

[Kay Martinen]

Am 27.09.22 um 12:27 schrieb Marc Haber:

> "Peter J. Holzer" <hjp-u...@hjp.at> wrote:
>> On 2022-09-26 18:31, Marc Haber <mh+usene...@zugschl.us> wrote:
>>> Vielleicht sollten wir (=Debian) besser von "buildable Packages" und
>>> "installable Packages" reden.
>>
>> Wäre eindeutiger, ja. Hat sich aber halt so eingebürgert.
>
> Erschwerend kommt die Negation hinzu, wenn ein Paket "unbuildable"
> oder "uninstallable" ist dann ist es kaputt.

Die Negation der Negation ist aber auch unmöglich. Oder kann es
"unbreakable" Pakete geben? :)