Network install - what's the point of installing obsolete packages?

geuder · July 2, 2011, 6:05pm

I made a network install of a new 11.4 system yesterday. It went all fine, but I was suprised that at the end of the installation some 80 packages required updating.

So what’s the point in installing obsolete versions first? A significant amount of time is wasted downloading and installing packages, which will be replaced shortly thereafter. Of course that’s the way it works for a media-based installation, because one does not want to create, test and release new installation media everytime a package is updated. But in network installation all it would take is to use the repository with the updated version.

The only argument I could imagine is that an updated package could make the installation fail. Installation with original packages has gonew through some QA. Well yes, of course it’s all software, so everything can fail. But when you install updates into your production system there is always the theoretical risk that they contain a fatal bug causing damage. For a new installation the damage would be much smaller, should the installation fail because an untested combination of package version happens not to install cleanly.

Or is there another reason I’m missing?

Regards,

Uwe

jdmcdaniel3 · July 2, 2011, 6:53pm

I made a network install of a new 11.4 system yesterday. It went all fine, but I was surprised that at the end of the installation some 80 packages required updating.

So what’s the point in installing obsolete versions first? A significant amount of time is wasted downloading and installing packages, which will be replaced shortly thereafter. Of course that’s the way it works for a media-based installation, because one does not want to create, test and release new installation media every time a package is updated. But in network installation all it would take is to use the repository with the updated version.

The only argument I could imagine is that an updated package could make the installation fail. Installation with original packages has go new through some QA. Well yes, of course it’s all software, so everything can fail. But when you install updates into your production system there is always the theoretical risk that they contain a fatal bug causing damage. For a new installation the damage would be much smaller, should the installation fail because an untested combination of package version happens not to install cleanly.

Or is there another reason I’m missing?

Regards,

Uwe

When openSUSE 11.4 was released, so were all of the installation media and methods. The developers are now working on openSUSE 12.1 and generally don’t go backwards and redo older releases, even if it was the last major one unless a grievous problem exists. The repositories on the other hand are almost constantly updated for security and feature additions. Everyone trying to keep openSUSE up to date will have the same updates as you with the default repositories being added for you. You could chose to not update and stick with what you got or following the products up like the rest of us do. Like most such projects as openSUSE, if someone popped up, able to make such package updates to the installation media without braking the installation, their help would be accepted I am sure. A lot of people do not realize the effort required to push out a complete and able to install package as every product update could effect the whole thing. Since efforts are often limited, that effort is put for on the next release and not on the past one. But maintainers do exist to keep our existing releases in our repositories up to date for our PC’s and for that I am grateful.

Thank You,

DenverD · July 2, 2011, 6:50pm

On 07/02/2011 06:06 PM, geuder wrote:
>
> So what’s the point in installing obsolete versions first?

so, every eight months a new version of openSUSE is released in the form
of iso’s which can be downloaded and installed…

those iso never change…ever. you download an iso, install from it and
it is immediately updated with the latest patches and security fixes…

if you don’t want to do it that way, you can elect to do the offered
Network install (on the download page right below “Live KDE” offer…

picking that and you get a very small initial download of a boot iso
which once you boot from it, all the other packages come from online
repositories…but, guess what! still it will install the same rpm
packages frozen on the release day, and then patch them all from the
update repo…

–
DD
-Caveat-Hardware-Software-

geuder · July 2, 2011, 8:03pm

Exactly. But why? It wuld not be any major effort to put the URL of the update repo into the networker installer ISO right from the beginning.

geuder · July 2, 2011, 8:17pm

I did not ask why we don’t get new installation media all the time. Of course that’s a resource question, and you get what you pay for (actually much more in this case,because most of us did not pay for the original release either)

Exactly. So what hinders the network installation to use also the repositories, which are up to date? The resolver would do the work to choose the newest version, no volunteer is needed for that.

I guess the update repos must have some kind of “supported” status, too, After all they are enabled by default. Otherwise I would not understand the logic. If the released version were more QA:ed or supported in whatever way than the updates, why would the update repos be enabled in the released version by default. Even the installer wants to install updates at the end of the installation by default.

martin_helm · July 2, 2011, 8:42pm

geuder wrote:
>
> Exactly. So what hinders the network installation to use also the
> repositories, which are up to date? The resolver would do the work to
> choose the newest version, no volunteer is needed for that.
>
There is a technical difference between the update repos and the repos where
the original rpm’s come from. The update repos contain patches to reduce the
download size and not the full rpm with the newer version. Technically to be
able to apply a patch (a so called delta) first the original rpm has to be
installed and later the patches can be applied.
I think so far there is no deeper philosophy behind that just a pure
technical reason. It would probably be a waste of resources to also keep
always the full newer versions of the rpms in the update repository.

martin_helm · July 2, 2011, 8:42pm

geuder wrote:

>
> DenverD;2360563 Wrote:
>> but, guess what! still it will install the same rpm
>> packages frozen on the release day, and then patch them all from the
>> update repo…
>> -
>
> Exactly. But why? It wuld not be any major effort to put the URL of the
> update repo into the networker installer ISO right from the beginning.
>
>
That would not help, see my other post.

geuder · July 2, 2011, 9:45pm

Well if that is the case, it explains everything of course.

I’m more a .deb guy, so I have never really understood how “-t patch” .rpms work.

But I’ strongly guess when the new rpm is build the first result is a full .rpm that can be installed. I’d guess the patch is produced as a kind of delta of the 2 versions. So do you really say the full new version is not kept online after producing the delta?

Another point the makes me wonder if your explanation is correct: I have installed 10s of packages manually later during the lifetime 11.3, I’d assume also from standard OpenSUSE repos. But I don’t remember that in a single case the package installed was already “obsolete” and required an immediate update.

geuder · July 2, 2011, 10:16pm

That doesn’t seem to be the case. Look at Index of /update/11.4-test/rpm/x86_64 for example.

When I did the network install I got dosfstools-3.0.10-11.1.x86_64 first. Afterwards it was updated to build 12.3.1.

The update repo does indeed contain a 11.1_12.3.1 delta rpm. But it also contains the full 12.3.1 rpm.

So even though the delta can be used during the update operation, installing the new version from the beginning would be faster.

P.S. When looking at this it appears to me that -t patch and delta rpms are different things. But that does not change my conclusion.

DenverD · July 2, 2011, 10:27pm

On 07/02/2011 10:06 PM, geuder wrote:
> But I don’t remember that
> in a single case the package installed was already “obsolete” and
> required an immediate update.

i believe the package manager is ‘smart enough’ to deliver both original
and patch, and install-patch in one operation…

–
DD
-Caveat-Hardware-Software-
.~.
/V
/( )
^^-^^

martin_helm · July 2, 2011, 10:56pm

DenverD wrote:

> On 07/02/2011 10:06 PM, geuder wrote:
>> But I don’t remember that
>> in a single case the package installed was already “obsolete” and
>> required an immediate update.
>
> i believe the package manager is ‘smart enough’ to deliver both original
> and patch, and install-patch in one operation…
>
I was a bit too fast and wrong in some detail. I inspected the update
repository and found that it contains all the delta rpm’s AND the latest
version as a full rpm.
So I stand corrected, pointing at the update repo while the initial install
runs should lead to an up to date system without running the updates in a
second step. I think the reasons why this is not used as default can then
only be answered by the people responsible for the installer, my theory was
wrong
The package manager just fetches the full rpm from the update repo, I tested
quickly with a package I had not yet installed and where a newer version in
update than in oss is available (I checked with thunderbird, since I never
install it).

robin_listas · July 3, 2011, 5:20pm

On 2011-07-02 18:06, geuder wrote:
> Or is there another reason I’m missing?

Ask in the factory mail list - the devs who could know are there.

It is a good question, I didn’t know that. I’m surprised by your finding.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

robin_listas · July 3, 2011, 5:20pm

On 2011-07-02 20:42, martin_helm wrote:
> The update repos contain patches to reduce the
> download size and not the full rpm with the newer version.

They contain both. Look with a browser and you will see.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

martin_helm · July 3, 2011, 5:30pm

Carlos E. R. wrote:

> On 2011-07-02 20:42, martin_helm wrote:
>> The update repos contain patches to reduce the
>> download size and not the full rpm with the newer version.
>
> They contain both. Look with a browser and you will see.
>
I already corrected that statement 19 hours ago.

malcolmlewis · July 3, 2011, 5:44pm

Hi
By default it will use the delta, you need to configure zypper to not use the deltas…


From /etc/zypp/zypp.conf;

##
## Whether to consider using a .delta.rpm when downloading a package
##
## Valid values: boolean
## Default value: true
##
## Using a delta rpm will decrease the download size for package updates
## since it does not contain all files of the package but only the binary
## diff of changed ones. Recreating the rpm package on the local machine
## is an expensive operation (memory,CPU). If your network connection is
## not too slow, you benefit from disabling .delta.rpm.
##
# download.use_deltarpm = true

robin_listas · July 3, 2011, 5:38pm

On 2011-07-03 17:30, martin_helm wrote:
> Carlos E. R. wrote:

> I already corrected that statement 19 hours ago.

I saw that later.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

martin_helm · July 3, 2011, 6:27pm

malcolmlewis wrote:

>
> Hi
> By default it will use the delta, you need to configure zypper to not
> use the deltas…
Only for packages where a previous version is already installed. Try it with
a package which you have not installed. It does not fetch the old one and
applies then the deltas, it directly downloads the full newest one from the
updates with the default settings in zypp.conf.