Balíčky pro Debian - 10 (speciální balíčky) (diskuse)

[Jirka P]

Překlep: s/libbar-bar/libbar-dbg/

MMCH, ta závislost (Suggests:) mezi daty a knihovnou je standardní praxe? V archivu jsem na toto téma našel všehochuť, od Depends: libbar0 přes Recommends a Suggests až po Conflicts: libbar0 (< x). Dá se nějak zařídit, pokud jsou data a "knihovna" v jiném balíčku (případ některých her), aby data šla nainstalovat samostatně, ale do testingu šly ty balíčky pouze v kompatibilních verzích (a nestalo se tedy, že nová data vyhodí starou binárku)?

[Jirka P]

Ještě ty -dbg balíčky: nestálo by za to (nedá se zařídit) mít i -dbg balíčky se soname? Když mi segfaultne program, který ještě nepřešel na libbar1 (používá libbar0), je mi libbar-dbg pro libbar1 platný jak mrtvýmu zimník. Jaký jsou pravidla pro mazání z testingu, umožňovaly by to?

[Michal Čihař]

No v článku to tak bylo zamýšleno . Je to čistě na tom, kdo balíčky vytváří a na tom co považuje za pravděpodobnější (ostatně to samé platí pro -dev balíčky).

[Michal Čihař]

Spíš s/libbar0-bar/libbar0-dbg/ ne?

Knihovna obvykle musí mít data, takže závislost z knihovny na data musí být Depends. Opačně to není nutné, protože data je třeba možná použít i v něčem jiném (at už to je jakkoliv pravděpodobné). A ani to není dobré, protože by vzniknul kruh závislostí a to může způsobit problémy při instalaci. To jestli tam bude Suggests nebo Recommends, je víceméně na správci. Konflikt může být na místě pokud nová verze dat nějak rozbíjí knihovnu, ale spíš bych to řešil závislostí knihovny na správné verzi dat.

No pokud jsou data ve stejném zdrojovém balíčku, tak se nemůže stát, že budou migrovat samostatně. Jinak je potřeba mít závislosti tak, aby samostatná migrace nemohla nastat.

[Jirka P]

Opačně to není nutné, protože data je třeba možná použít i v něčem jiném (at už to je jakkoliv pravděpodobné).

Tady bych byl opatrný, pokud maintainer myslí, že libbar0-data je možno použít i jinak než v libbar0, měl by zároveň garantovat nějakou funkčnost balíku libbar0-data. Což ho omezuje v takových akcích jako smazání půlky souborů v nějaké revizi.

A ani to není dobré, protože by vzniknul kruh závislostí a to může způsobit problémy při instalaci.

Dost by mě zajímalo, čím a jaké problémy to způsobuje. Vím, že o tom čas od času jistý B.A. vyvolá na -⁠devel flame, ale ty jeho zdůvodnění jsou tak trochu divný. Že cokoli rozbije dist-upgrade nic neznamená, dist-upgrade je rozbitý sám o sobě. Že to zvětšuje složitost vyhodnocování a splňování závislostí prostě není pravda. Problémy s pořadím spouštění instalačních skriptů sice můžou být, ale ne pokud jeden z těch balíků ty skripty nemá atd.

Jinak je potřeba mít závislosti tak, aby samostatná migrace nemohla nastat.

No jo, ale jak to udělat?

[Michal Čihař]

Dost by mě zajímalo, čím a jaké problémy to způsobuje. Vím, že o tom čas od času jistý B.A. vyvolá na -⁠devel flame, ale ty jeho zdůvodnění jsou tak trochu divný. Že cokoli rozbije dist-upgrade nic neznamená, dist-upgrade je rozbitý sám o sobě. Že to zvětšuje složitost vyhodnocování a splňování závislostí prostě není pravda. Problémy s pořadím spouštění instalačních skriptů sice můžou být, ale ne pokud jeden z těch balíků ty skripty nemá atd.

Spíš bych ten problém formuloval opačně: jaký je dobrý důvod k vytvoření kruhové závislosti? V mnoha případech sice problém nezpůsobí, ale to není důvod jich mít v distribuci stovky a komplikovat tak jakýkoliv upgrade.

Jinak je potřeba mít závislosti tak, aby samostatná migrace nemohla nastat.

No jo, ale jak to udělat?

Při migraci se kontroluje jestli se nerozbijí závislosti jiných balíčků, takže pokud potřebuju nějakou verzi dat, stačí to dát do závislostí, např.:

Package: program
Depends: data (>= 1.0), data (<< 1.1)