[UBK dev] kdeapps

Kiss Attila attus at enterpriseforever.com
2016. Dec. 22., Cs, 17:10:54 CET



2016-12-22 00:16 keltezéssel, Páder Rezső írta:
>
> Igazából 3 dolog dönti el, hogy kell-e dev csomag:
> - csomag funkciója: ha más csomag is igényli .h / lib szinten fordításkor,
>    akkor szinte biztosan kell.
> - csomag tartalma: még ha kell is más csomagnak az adott csomagban lévő .h
>    vagy lib, de pl. csak egy .h, egy .la és egy .pc fájl van benne a fő lib
>    mellett, akkor ezeket nem muszáj külön dev csomagba tenni (pl.
>    x.org-input-evdev ilyen). Csak fejléceket (pl. mdds), vagy csak statikus
>    libeket (.a van, de .so nincs, pl. jansson, vc) sem kell szétbontani.
> - csomag függőségei: ha a kész csomag függőségei között van -dev csomag, és
>    az új csomag nem csak csomagkészítéshez, fordításhoz kell, akkor mindig
>    kell dev csomag. Pl. a kdoctools felteszi a karchive-dev és a qt5-dev
>    csomagokat, viszont a kdoctools szerepe az, hogy fordítás közben elkészít
>    bizonyos dokumentációkat, így a kész csomagnak nem kell belőle semmi -
>    így nem gond, hogy függ a karchive-dev és qt5-dev csomagoktól. De ha a
>    pl. a vlc videolejátszó függőségei között ott lenne a glibc-dev, az már
>    baj lenne - ezért van neki külön dev csomag.

Ehhez én még csak hozzáfűzöm az én stratégiám egy részét, mely lehet, 
hogy nem talál egyetértésre.

Az én mániám már évek óta az, hogy ne legyen egyetlen olyan, elsősorban 
a felhasználóknak és nem kizárólag a fejlesztőknek szánt csomagunk sem, 
mely az illető csomagot feltelepítve teljesen felesleges sallangokat is 
feltelepítsen pluszban, olyanokat, amik az illető program kifogástalan 
működéséhez valójában teljesen feleslegesek.
Ha valamelyik csomag egy *.pc -t felrak, akkor már én azonnal csinálok 
egy lehasított dev csomagot is belőle, mert ez máris egy rakás dev 
csomag feltelepítését eredményezi. Ez alól nálam csak akkor van kivétel, 
ha a konkrét csomag csakis fordítási, vagy fejlesztői célt szolgál, azaz 
akár lehetne a fő csomag neve valami-dev, hasítás nélkül.

Az én feltelepített rendszeremen nincs is egyetlen *-dev csomag 
feltelepítve és nem is tűrök meg rajta ilyet. a *-dev csomagoknak 
számomra csakis a fordítási chrootban van létjogosultságuk.

Ha fejlesztő lennék és nem csomagoló, akkor más lenne az ábra, mert egy 
fejlesztői IDE használata esetén már bizony sokszor szükség lehet és van 
mindenfále fejlécre és fordítóra. Egy normál átlagos júzernek, aki csak 
a csomagkezelővel telepítget, még a make, gcc, cmake programok is 
feleslegesek.

Most nézem, a gcc nálam csak ccache miatt van feltelepítve.

>> libkomparediff2: ez nem tudom hogy a kde szekcióba kerüljön, vagy inkább
>> a libek közé?
> KDE.
> Iránymutatásként: amit a kde.org-ról, vagy a github.com/KDE alól szedsz le,
> az minden KDE section, bármit csinál.
> (Ugyanez érvényes a Mate és az Xfce esetében is: ami a saját letöltési
> oldalukról, forrásukból származik, az minden MATE illetve XFCE section.
> Sok esetben ugyanis nagyon nehéz összeszedni egy-egy desktop komponenseit,
> ez főleg a két legnagyobbra igaz: a kde már most 137 ub-t jelent, a
> gnome-ot saccolni sem tudom, az még nincs átállítva a GNOME section
> használatára. No meg sokszor nem is egyértelmű a besorolás: pl. a
> gnome-menus nem csak egy lib, hanem a gnome menü szerkezetét
> adó .menu, és .directory fájlok is kellenek neki, amik viszont inkább a
> Data kategóriába tartoznának... Így egyszerűbb: ami kde, az kde.)

Apropó, ha már egységesítés...

Mi legyen a cinnamon, lxqt, lxde cuccokkal?

Például most a cinnamon categories értéke CINNAMON, és a secton 
Applications/WindowManagers.

Átállítsam a categories értékeket legalább github ub szinten az 
egyértelműeket LXDE, CINNAMON, LXQT értékre?

A másik kérdésem, hogy egy csomó fenti elemnél nincs is categories fájl, 
ez pótolandó?
Az uhubuild-check ezt mintha nem is ellenőrizné, főleg a tartalmát nem.




More information about the dev mailing list