Hi,

I've just started to do research in order to write a tool which I was
always missing. What I have so far is just a brief "background"
information, explaining the problem - see below.

I thought it might be good to ask here if I'm not trying to reinvent
something that already exists. Or maybe someone has some ideas about
this issue?

| Background
| ----------
|
| Maintaining Debian stable systems sometimes requires installation of
| unofficial versions of packages:
|
| - backporting newer versions, when significant new functionality is
| required on the system but unavailable in the official version found
| in the current stable release. In this case, the version string
| usually sorts as newer than the official stable version string. This
| means that pinning is not necessary, as apt will upgrade such package
| by default.
|
| - making local changes to the official version. In this case, the most
| reliable way is to make the version string sort as older than the
| official one (using the "tilde" feature of dpkg) and force
| installation of such package using pinning. (The other strategy:
| trying to invent a version string newer than the current one, but
| older than the next one is difficult to do reliably.)
|
| In both cases, there is one major drawback: apt will not warn you where
| newer versions of official packages (point releases, security updates)
| will appear in the stable release. This means you may miss some
| important change.
|
| The point of this document is to design a utility whose job is to do
| exactly this: let you track newer official versions of locally overriden
| packages.
|

--
Marcin Owsiany <porridge@debian.org> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

[Marcin Owsiany]
> I thought it might be good to ask here if I'm not trying to reinvent
> something that already exists. Or maybe someone has some ideas about
> this issue?

One idea that occured to me, was to use the information collected by
popularity-contest to see how many are using backported packages and
locally changed packages, and also which packages this happen to. It
could be input to the stable release managers on which packages to
update in stable.

Happy hacking,
--
Petter Reinholdtsen


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Hello,

Marcin Owsiany wrote:
> | - making local changes to the official version. In this case, the most
> | reliable way is to make the version string sort as older than the
> | official one (using the "tilde" feature of dpkg) and force
> | installation of such package using pinning. (The other strategy:
> | trying to invent a version string newer than the current one, but
> | older than the next one is difficult to do reliably.)

In that case, a solution that comes to my mind is to use the Forbid
feature of aptitude: you install the locally-modified version and forbid
the version currently in stable. This way, aptitude won't install it,
but it will upgrade to a later version if there is one.

Of course, you'll still have to prepare a new version based on the new
one, but at least, you'll notice there is an upgrade available.

Cheers,

Vincent

--
Vincent Fourmond, Debian Developer
http://vince-debian.blogspot.com/

It was funny how people were people everywhere you went, even if the
people concerned weren't the people the people who made up the phrase
``people are people everywhere' had traditionally thought of as people.
-- Terry Pratchet, The Fifth Elephant

Vincent, listening to Darlene (Led Zeppelin)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On 10/08/08 at 09:42 +0200, Petter Reinholdtsen wrote:
> [Marcin Owsiany]
> > I thought it might be good to ask here if I'm not trying to reinvent
> > something that already exists. Or maybe someone has some ideas about
> > this issue?
>
> One idea that occured to me, was to use the information collected by
> popularity-contest to see how many are using backported packages and
> locally changed packages, and also which packages this happen to. It
> could be input to the stable release managers on which packages to
> update in stable.

popularity-contest doesn't include information about packages' versions.
--
| Lucas Nussbaum
| lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Marcin Owsiany wrote:
> I've just started to do research in order to write a tool which I was
> always missing. What I have so far is just a brief "background"
> information, explaining the problem - see below.

I agree that this is a missing feature ATM: to be able to see at a glance
which packages did not come from the regular repository or have newer
versions than available from registered repositories.

However, I would actually prefer this to be integrated in the regular
package management frontends (e.g. aptitude) rather than a separate tool.

If the source of the package is in /etc/apt/sources.list, it should be
trivial to create a new view and/or informational fields that show where
an installed version comes from: regular archive, security, volatile,
external archive. Or, if there are no matches to show it as locally
installed.

If there are multiple potential sources some kind of ordering may be
needed [1] as may handling of CD sets.

Cheers,
FJP

[1] 'apt-cache policy <package>' essentially already does ordering

On Thursday 14 August 2008 03:00, Frans Pop wrote:
> Marcin Owsiany wrote:
> > I've just started to do research in order to write a tool which I was
> > always missing. What I have so far is just a brief "background"
> > information, explaining the problem - see below.
>
> I agree that this is a missing feature ATM: to be able to see at a glance
> which packages did not come from the regular repository or have newer
> versions than available from registered repositories.
>
> However, I would actually prefer this to be integrated in the regular
> package management frontends (e.g. aptitude) rather than a separate tool.

I put in +1 to that. Nothing to add.
>
> If the source of the package is in /etc/apt/sources.list, it should be
> trivial to create a new view and/or informational fields that show where
> an installed version comes from: regular archive, security, volatile,
> external archive. Or, if there are no matches to show it as locally
> installed.
>
> If there are multiple potential sources some kind of ordering may be
> needed [1] as may handling of CD sets.
>
> Cheers,
> FJP
>
> [1] 'apt-cache policy <package>' essentially already does ordering

--
Shachar Or | שחר �ור
http://ox.freeallweb.org/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Frans Pop wrote:
However, I would actually prefer this to be integrated in the regular
package management frontends (e.g. aptitude) rather than a separate tool.

aptitude will show that different versions of a package are available.
Unfortunately it won't show where these different versions come from, so
it isn't always easy to, say pick the testing version if you have
multiple sources. Sometimes I accidentally pick the package by its
unstable name without realising the name has changed and wonder why I
have problems trying to install it. As I result I often create a new
shell so I can use the following:

[1] 'apt-cache policy <package>' essentially already does ordering



Brian May


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Sun, Aug 10, 2008 at 09:59:32AM +0200, Vincent Fourmond wrote:
>
> Marcin Owsiany wrote:
> > | - making local changes to the official version. In this case, the most
> > | reliable way is to make the version string sort as older than the
> > | official one (using the "tilde" feature of dpkg) and force
> > | installation of such package using pinning. (The other strategy:
> > | trying to invent a version string newer than the current one, but
> > | older than the next one is difficult to do reliably.)
>
> In that case, a solution that comes to my mind is to use the Forbid
> feature of aptitude: you install the locally-modified version and forbid
> the version currently in stable. This way, aptitude won't install it,
> but it will upgrade to a later version if there is one.

I must admit that I did not know this particular feature of aptitude.
However after having a look at the documentation, it does not seem to be
the right tool in the case which is most interesting for me, that is
automated package management on distributed hosts. It seems like you
need to at least run a command on each host for each package/version
combination that you do not like. Does not sound really scalable,
especially combined with the fact that "only one version can be
forbidden at once."

Moreover, even though I find aptitude indispensable on a desktop, I
refrain from using it for automation due to things like #445035 or
#445034.


I've started coding now, but for several reasons I decided to implement
it in python (using python-apt). If it works, then it can always be
treated as a prototype and reimplemented as an apt-cache subcommand.

--
Marcin Owsiany <porridge@debian.org> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org