Debian Puts Out New APT 1.1 Pre-Release "Supercow Powers"

[phoronix]

Phoronix: Debian Puts Out New APT 1.1 Pre-Release "Supercow Powers"

Announced today from DebConf '15 during a talk entitled "This APT has Supercow Powers" is the ninth preview release of APT 1.1...

http://www.phoronix.com/scan.php?page=news_item&px=APT-1.1-Supercow-Powers

[profoundWHALE]

Debian, "fixing" what isn't broken since November 18th, 2014.

If you read the release notes, you'd see that there were (IMO) some much needed changes to the retrieval process that'll fix most of my issues with APT.

[DanL]

Debian, "fixing" what isn't broken since November 18th, 2014.

Your probably mean the 28th. Anyway, this news release has nothing to do with systemd or init systems, so go take your tired 'cancerd' act elsewhere...

[carewolf]

If only they could separate metadata out of the deb-packages so that the metadata could be updated separately of the content, now THAT would solve the last major deficiency of APT. Well that and maintain security patch relations, so you get them in rolling releases (acknowleding most debian users are on testing or unstable, and not updating dayly).

[discordian]

If only they could separate metadata out of the deb-packages so that the metadata could be updated separately of the content, now THAT would solve the last major deficiency of APT.

Why would you want this, what metadata do you want to update?
To me a selfcontained file (ok, ignore the depencies) is easier to handle than 2 files. And internally the installation files are archived seperately from the installation metadata, so you could easily write a script or tool to replace the metadata.

[profoundWHALE]

Why would you want this, what metadata do you want to update?
To me a selfcontained file (ok, ignore the depencies) is easier to handle than 2 files. And internally the installation files are archived seperately from the installation metadata, so you could easily write a script or tool to replace the metadata.

You'd be more for the .snap packages that seem to have all the dependencies contained

[discordian]

You'd be more for the .snap packages that seem to have all the dependencies contained

No, I am not. Or atleast Im rather skeptical about it since I already can and do bundle libraries with .deb on occasions and dont see why this should be the default, let alone - if I ship a single app with private libs I would want to link them statically wherever possible (license). I am not happy with having dozens of C Runtimes installed in Windows and I believe snappy will favor such a mess instead of putting emphasis about singular, backwards compatible libs.

I am merely curious about the usecase that would require just updating the metadata or even having it as separate file (like carewolf requires)

[carewolf]

Why would you want this, what metadata do you want to update?
To me a selfcontained file (ok, ignore the depencies) is easier to handle than 2 files. And internally the installation files are archived seperately from the installation metadata, so you could easily write a script or tool to replace the metadata.

Conflicts with other (new) packages and errors in metadata. Those are actually the majority of updates, it is quite silly we have to download and install identical content just because the metadata needs to be refined.

[discordian]

Hmm, those are rather rare in my experience. are you on an older version of debian and sticking to security-updates?

If unnecessary updates are a concern, well, debian packages are build from sources and often result in multiple packages. Take for example https://packages.debian.org/source/jessie/gcc-4.9 , it builds dozens of binary packages. A change in code only affecting, say libatomic, will result in all other packages being updated without them having effective changes aswell (there might still be binary differences thanks to compiled-in datestamps for example).

That hit me a few times when I fixed a few errors in a small shell script and had to compile and upload multiple resulting (rather big and timeconsuming) packages. Fixing this would require a new concept like using hashes to detect changed files - and you still couldn't automatically deduce which packages are affected by changing one file.