FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 11-15-2010, 11:34 AM
Lukas Linhart
 
Default Downgrading packages (with dependencies)

Hi,

we're building packages with concept of "metapackage": package whose only
purpose is to specify particular versions it depends on.

Problem is, we'd like to be able to downgrade. However. I did not found the
option to "force download in dependency chain"; when metapackage is being
downgraded, all dependencies forced to download must be specified on command
line (with version to download to).

This is very annoying and yields whole downgrade concept unusable.

Is there any way to force said behavior or work around it?

Thanks,

Almad


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201011151334.06503.lukas.linhart@centrumholdings.c om">http://lists.debian.org/201011151334.06503.lukas.linhart@centrumholdings.c om
 
Old 11-15-2010, 06:39 PM
Bob Proulx
 
Default Downgrading packages (with dependencies)

Lukas Linhart wrote:
> we're building packages with concept of "metapackage": package whose only
> purpose is to specify particular versions it depends on.

Sounds good. It is very commonly done.

> Problem is, we'd like to be able to downgrade. However. I did not found the
> option to "force download in dependency chain"; when metapackage is being
> downgraded, all dependencies forced to download must be specified on command
> line (with version to download to).
>
> This is very annoying and yields whole downgrade concept unusable.
>
> Is there any way to force said behavior or work around it?

No. In general downgrades are not supported. Packages are held
accountable to ensure that their installation scripts (preinst, prerm,
postinst, postrm, etc.) all behave correctly during upgrades. There
isn't any systematic testing or requirement that they operate
correctly on downgrades. Some do and some don't.

For example packages may convert configuration files forward from old
formats to new formats. But I don't know of any that convert new
formats to old formats when downgrading.

Therefore apt and dpkg require extra confirmation that you know what
you are doing when you request a downgrade. You can't upgrade a meta
package that depends upon a specific older dependency. That appears
to the system more like a problem than a feature and so it is
disallowed.

If you want to do this then the best you can do is to create a script
that installs the packages that you need by specific version and then
'holds' them. Tools like /bin/sh, cfengine, puppet, chef, all come to
mind.

Bob
 
Old 11-15-2010, 06:44 PM
Camaleón
 
Default Downgrading packages (with dependencies)

On Mon, 15 Nov 2010 13:34:06 +0100, Lukas Linhart wrote:

> we're building packages with concept of "metapackage": package whose
> only purpose is to specify particular versions it depends on.

Then I'm afraid you'll receive more advice in "debian-devel" :-)

> Problem is, we'd like to be able to downgrade. However. I did not found
> the option to "force download in dependency chain"; when metapackage is
> being downgraded, all dependencies forced to download must be specified
> on command line (with version to download to).
>
> This is very annoying and yields whole downgrade concept unusable.
>
> Is there any way to force said behavior or work around it?

I find the concept interesting.

First, because I was not aware that a metapackage could be "itself" up/
downgraded :-?

Second, because if I understood your point correctly, you are looking for
a chain-downgrade that force the user to auto-install an old version of
single packages due to metapackage dependencies...

For example, let's imagine we have a metapackage called "my-meta-1" that
will depend on (install) "my-meta1-sub1", "my-meta1-sub2" and "my-meta1-
sub3". Are you suggesting that when the user downgrades to "my-
meta-0.9" (is that even possible?) it automatically downgrades the other
packages it depends on?

Then, what happens if a user wants to keep (or even "upgrade") separately
one of the "my-meta1-sub1"? Can a metapackage enforce that policy? AFAIK,
a metapackage is just a heap of packages that are to be installed but
each package has its own dependencies and requirements to be fulfilled,
so I wonder if a metapackage has its own entity inside the packaging
system...

What a mess! O:-)

Greetings,

--
Camaleón


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: pan.2010.11.15.19.44.46@gmail.com">http://lists.debian.org/pan.2010.11.15.19.44.46@gmail.com
 
Old 11-15-2010, 06:55 PM
"Boyd Stephen Smith Jr."
 
Default Downgrading packages (with dependencies)

In <201011151334.06503.lukas.linhart@centrumholdings. com>, Lukas Linhart
wrote:
>Problem is, we'd like to be able to downgrade. However. I did not found the
>option to "force download in dependency chain"; when metapackage is being
>downgraded, all dependencies forced to download must be specified on command
>line (with version to download to).

You could use a == instead of an >= version restriction. This is used in a
few places in the Debian archive to keep two inter-related packages in lock-
step. aptitude/apt/dpkg will still likely complain if any package needs to be
downgraded, though.

Using == for a metapackage is largely frowned upon though. It gums up the
works when a single package needs a security update.

>This is very annoying and yields whole downgrade concept unusable.

Downgrades aren't supported and can't reasonably be supported in general.
Specifically, it is impossible to modify the lower-versioned package to
account for changes brought in by the higher-versioned package.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
 
Old 11-16-2010, 09:48 AM
Linhart Lukas
 
Default Downgrading packages (with dependencies)

> Then I'm afraid you'll receive more advice in "debian-devel" :-)

Oh, I'll perhaps try. Thanks.

> I find the concept interesting.

> First, because I was not aware that a metapackage could be "itself" up/
> downgraded :-?

"metapackage"is usial package, not virtual package.

> Second, because if I understood your point correctly, you are looking for
> a chain-downgrade that force the user to auto-install an old version of
> single packages due to metapackage dependencies...

Yes.

> Are you suggesting that when the user downgrades to "my-
> meta-0.9" (is that even possible?) it automatically downgrades the other
> packages it depends on?

> Then, what happens if a user wants to keep (or even "upgrade") separately
> one of the "my-meta1-sub1"?

Than he has to uninstall metapackage, as he will not fullfill dependency requierments. Also, he will end up with unworky packages and he will have combination of apps that is not supported.

> AFAIK,
> a metapackage is just a heap of packages that are to be installed but
> each package has its own dependencies and requirements to be fulfilled,
> so I wonder if a metapackage has its own entity inside the packaging
> system...

Again, this is probably bad term, I'm not talking about virtual packages.

> Camaleón

Almad


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 95BE811F783DF74AB7D6ACE32D620605188D4E@HERMES.offi ce.netcentrum.cz">http://lists.debian.org/95BE811F783DF74AB7D6ACE32D620605188D4E@HERMES.offi ce.netcentrum.cz
 
Old 11-16-2010, 12:38 PM
"Jesús M. Navarro"
 
Default Downgrading packages (with dependencies)

Hi, Boyd:

On Monday 15 November 2010 20:55:58 Boyd Stephen Smith Jr. wrote:
> In <201011151334.06503.lukas.linhart@centrumholdings. com>, Lukas Linhart
[...]

> Downgrades aren't supported and can't reasonably be supported in general.
> Specifically, it is impossible to modify the lower-versioned package to
> account for changes brought in by the higher-versioned package.

It's true that they are not currently supported on Debian, but I don't see
that they can't be supported.

Downgrade shouldn't be considered as an "upgrade, only to a lower version" but
more as of a rollback: regarding configs and binaries it seems not so
complex; just recover whatever was there prior to the upgrade; regarding
formatted data (i.e. a database), yes, there is a problem, since there's no
guarantee that the old data model will be able to hold data added by the new
one but, again, considered as a rollback it's affordable: you can recover
whatever data was by the upgrade time (or you can add a manual hook akind of
that when a config conflict is detected, so the user can manually handle it).

Cheers.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201011161438.54964.jesus.navarro@undominio.net">ht tp://lists.debian.org/201011161438.54964.jesus.navarro@undominio.net
 
Old 11-16-2010, 08:31 PM
"Boyd Stephen Smith Jr."
 
Default Downgrading packages (with dependencies)

In <201011161438.54964.jesus.navarro@undominio.net> , Jesús M. Navarro wrote:
>Hi, Boyd:
>
>On Monday 15 November 2010 20:55:58 Boyd Stephen Smith Jr. wrote:
>> In <201011151334.06503.lukas.linhart@centrumholdings. com>, Lukas Linhart
>
>[...]
>
>> Downgrades aren't supported and can't reasonably be supported in general.
>> Specifically, it is impossible to modify the lower-versioned package to
>> account for changes brought in by the higher-versioned package.
>
>It's true that they are not currently supported on Debian, but I don't see
>that they can't be supported.
>
>Downgrade shouldn't be considered as an "upgrade, only to a lower version"

That is what a downgrade is, by definition.

>but more as of a rollback: regarding configs and binaries it seems not so
>complex; just recover whatever was there prior to the upgrade

That's something entirely different and intentionally not handled by the
packaging system. There are a few roll-your-own solutions available for
Linux, but I don't know of something like Apple's Time Machine that works out-
of-the-box.

The critical difference is that the packaging system restricts it's actions to
system-wide programs and data (and tries to concentrate as much as possible on
static data; avoiding as much as possible data that is modified during normal
operations), whereas a rollback has to include user-specific data which can be
very dynamic.

Yes, you have to the user's data as well. While packages don't install to
/home, running programs often write there and files written by the higher
versions of a program may not be readable by the lower versions of a program.

If you want rollbacks, get a system that handles rollbacks. Don't expect the
packaging system to do it as implicitly on a downgrade request.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
 
Old 11-17-2010, 03:23 PM
Lukas Linhart
 
Default Downgrading packages (with dependencies)

On Tuesday 16 of November 2010 22:31:20 Boyd Stephen Smith Jr. wrote:
> In <201011161438.54964.jesus.navarro@undominio.net> , Jesús M. Navarro wrote:
> >Downgrade shouldn't be considered as an "upgrade, only to a lower version"
>
> That is what a downgrade is, by definition.

In my case, this whould be enough.

I can see why it's not implemented, but it still presents hurdle for me and I
would welcome the --selfdestruct apt options.

Anyways, thanks for Your help. I'll try to work around those ones.

Almad


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201011171723.49522.lukas.linhart@centrumholdings.c om">http://lists.debian.org/201011171723.49522.lukas.linhart@centrumholdings.c om
 

Thread Tools




All times are GMT. The time now is 02:58 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org