winget - saját csomagkezelőt fejleszt a Microsoft


Windows Package Manager CLI (aka winget). Részletek itt. Forráskódok a GitHub-on: winget-cli

Hozzászólások

Csináltak egy symlinket az apt-getre a WSL-ben? :)

Először szerintem wget akart lenni, aztán leesett nekik, hogy az már foglalt :-D :-D

Itt most még csak nem is az apt féle függőség és repositorykezelésről beszélünk (mert az apt az nem a csomagkezelő, hanem a repo/dep. handler), hanem a csomagkezelésről: akár a Debian féle dpkg (ha már az apt-ot emlegettük), akár a BSD féle pkg tools, vagy a NeXT/OSX/macOS féle pkg installer, vagy akármi, a lényeg, hogy egységesen kezeli a rendszer csomagjait. Na ilyen nincs windows alatt, csak mindenféle 3rd party installer shieldek.

"csak mindenféle 3rd party installer shieldek"

Biztos, hogy mindegyik 3rd party? :)

Amugy a kedvencem az a retek 3rd party install shield, amelyik a futo user Users mappajaba telepit akkor is, ha az nem admin, de telepiteshez admin jog kene, igy ha crippled userkent vagy bejelentkezve, atloginol egy masik userbe, es utana a crippled useredkent nem talalod meg tobbet. Pedig a telepitett program futtatasahoz nem lenne szukseged admin jogokra.

Es 10-bol 8 torrent kliens erre a hulladek install shieldre bizta az installeret. De olyat is talaltam, amelyiknek a portable valtozata is elso futaskor az Admin users mappajaba ir, es onnan akar utana keresni dolgokat. :(

Nem az a szomoru, hogy ez az install shield letezik, hanem hogy hasznaljak.

Define rendszer. Az OS X-nek tudtommal nincs érdemi beépített csomagkezelője, mert az az elve, hogy egy alkalmazás, egy mappa. Aztán ott van az XCode CLI Tools, maga az XCode, meg a hozzá hasonló cuccok, amik a fél rendszert teleszórják fájlokkal. 

No meg a pkg/mpkg fajlok, amik annyira megbizhatoak, mint Windowson egy MSI.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

> Define rendszer.

Már definiáltad: "az az elve, hogy egy alkalmazás, egy mappa". Ennek megfelelően az sem érdekes, hogy "nincs érdemi beépített csomagkezelője", mert ott egy alkalmazás a per user settingset leszámítva a saját dirjében lakik. Ha ezzel valami szembemegy, akkor az más tészta. Szembemenni a dpkg-val, meg a többivel is lehet, csak minek. Csomagkezelő hiánya != csomagkezelés hiánya.

Az a baj, hogy az "egy alkalmazas - egy mappa" az nagyon nehezen hivhato csomagkezelesnek. Ubuntun is ossze lehet dobni egy olyan appot, ami a /opt/appneve mappaban lakik, fuggosegekkel egyutt, megsem hivjuk ezt csomagnak, illetve csomagkezelesnek, nem veletlenul.

A csomagkezelesnek resze a fuggosegkezeles, a frissithetoseg, a maradektalan eltavolithatosag. Na ez peldaul Macen nincs meg, sok alkalmazas hiaba egy mappaban van, kitesz (akar sziimbolikus linkeket is) a /usr/local ala, a /Library/LaunchDaemons mappaba, vagy mashova fajlokat, mappakat, szimbolikus linkeeket, ami az alkalmazas mappajanak eltorlesevel nem fog eltunni. A csomagkezelesnek ez is egy eleg fontos feladata is, hogy ezeket a kovetelmenyeket teljesiteni tudja, integralni tudja az alkalmazast az operacios rendszerbe. 

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

> Ubuntun is ossze lehet dobni egy olyan appot, ami a /opt/appneve mappaban lakik, fuggosegekkel egyutt, megsem hivjuk ezt csomagnak, illetve csomagkezelesnek, nem veletlenul.

De igen. A csomag egy szoftver összes cucca egy csomagban, amit egy művelettel tudsz telepíteni és/vagy eltávolítani. Nem egy Linux van, ami így működik hogy egy könyvtárban tart egy appot.

> A csomagkezelesnek resze a fuggosegkezeles

Nem feltétlenül. Van olyan csomagkezelő, ahol a függőségkezelés egyáltalán nem része a rendszernek. A csomagkezelőnek egyetlen kötelező feladata van: a csomagok kezelése. Ha a csomag amúgy is hozza magával a függőségeit, akkor nincs is milyen függőséget kezelni.

> a frissithetoseg, a maradektalan eltavolithatosag.

Ami egy olyan appnál, ami egy könyvtárra van korlátozva, maradéktalanul megvan.

> Na ez peldaul Macen nincs meg, sok alkalmazas hiaba egy mappaban van, kitesz (akar sziimbolikus linkeket is) a /usr/local ala, a /Library/LaunchDaemons mappaba, vagy mashova fajlokat, mappakat, szimbolikus linkeeket, ami az alkalmazas mappajanak eltorlesevel nem fog eltunni.

Ilyen felállás mellett ez egyik rendszeren sincs meg, mert ha az alkalmazás linkelget össze-vissza mindent a rendszerben, a csomagkezelő tudtán kívül, akkor az Linuxon, BSD-n, Solarison meg az összes többin is ottmaradó szemetet fog eredményezni.

> A csomagkezelesnek ez is egy eleg fontos feladata is, hogy ezeket a kovetelmenyeket teljesiteni tudja, integralni tudja az alkalmazast az operacios rendszerbe.

Még mindig nem. A csomagkezelőnek a telepítés/eltávolítás a feladata. Az "operációs rendszerbe való integrálás" feltételezi, hogy az OS-nek van bármilyen ilyen célt szolgáló centralizált felülete (anélkül ugyanis nehezen lehetne bármit is integrálni, ha egyszer nincs hova), márpedig ilyen egyetlen UNIX-ban sincs, ilyen egyedül windows alatt van: Registrynek hívják. Látjuk milyen frankón működik: pont ott van a legnagyobb kupleráj a csomagkezelést illetően.

de miert nem vettek meg a chocolateyt inkabb? az legalabb mukodik.

Nem emlékszem, de nem egy olyan dologról volt szó amit alapból choco-n keresztül telepítenék (AdobeReader, Chrome, FFox, VLC).
Ha tudtam volna pontosan, akkor odaírtam volna. Lehet hogy később, amikor lesz egy kis időm megkeresem, mert így valóban eléggé FUD-nak hat a kommentem.

Szerintem már volt egy ilyen projekt és éppen éppen win-get volt a neve. Jól emlékszem?

Ezt akartam kerdezni! En is ugy tudtam, mar van ilyenje az MS-nek.

Amugy itt alapvetoen szemleletvaltas kene a programfejlesztok iranyabol is. Mert addig OK, hogy lesz ilyenje az MS-nek, de ha nem lesznek kulsos repok, akkor mit ernek vele? Win-es szolgaltatasokat eddig is lehetett ps-el telepiteni...

Mondjuk kezdhetnek azzal a fejlesztok, hogy megoldjak vegre, hogy Core-on is normalisan menjenek azok az appok, amik nem is indokoljak egyaltalan a gui-t.... Nem egy Olyan Win-es programot lattam mar, ahol pl egy server/client felepitesu progi server resze nem ment fol/nem mukodott megfeleloen Core-on...

Elfogytak az ötletek, de van egy free ötlet doboz (Linux)

"ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett" 

és 100 éve még boszorkányt is égettek 

Szerkesztve: 2020. 05. 20., sze - 17:49

-

:D

C:\Documents and Settings\Felhasználó1> WinSudo Winget Install "Microsoft Office" "ABCDE-12345-FGHIJ-67891-KLMNO"

:D

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

Mivel a konfigurációs lehetőségekből van egy pár, ezért nem meglepő, hogy először egy konfig file-t kell létrehozni (egyszer): https://config.office.com/deploymentsettings

Utána letöltöd a file share-re a telepítőkészletet és a kliensen adminként:

\\Server\Share\M365\setup.exe /configure \\Server\Share\M365\config-broad-SAC.xml

Üdv,
Marci

Szerkesztve: 2020. 05. 21., cs - 16:05

.

Vége a vadnyugatról letöltött setup exék adminként futtatásának? Álmodom?

Szerkesztve: 2020. 05. 23., szo - 07:35

"The description claims this thing to be a package manager but in reality it has nothing to do either with packages or management.
All it does is downloading installers (which are not packages) and executing them (which is not management)." 

https://github.com/microsoft/winget-cli/issues/223

Hát igen... Emlékeztető arra, hogy az MS egy nagy vállalat és maradt benne bőven genyó részleg. Az az érthetetlen, hogy az ő szintjükön simán fizethettek volna valamennyit az AppGetért (ha már nem vették fel a készítőjét) vagy éppen több elismerő szót is írhattak volna róla a bejelentésben. Ehelyett csak a "futottak még" kategóriában említik az AppGet-et, érthető hogy ez a hozzáállás nem nagyon tetszett Keivannak.