Re: Last call before metapackage creation for Wheezy
[Please make sure to read PS below.]
On Wed, Apr 10, 2013 at 10:52:45AM +0200, Alexander Dreyer wrote:
> > However, you might have missunderstood the sense of the tasks ans thus
> Indeed, I missed the point: this will only add the outdated version.
That's kind of 'normal' that packages become outdated in the release
process. It might be reasonable to consider backports if you want to
make sure that users of Wheezy will be able to use the latest version.
There will be no problem when using the metapackages: The metapackage
ensures *that* a package will be installed. The user can specify from
what repository this will come and apt will pick the highest available
version from /etc/apt/preferences.
> > In contrast to the metapackage creation process (which was the topic of
> > my initial mail) the web pages you are linking to above are part of the
> > Blends web sentinel and updated daily and thus show a current snapshot
> > of all packages in Debian Science (independently from the distribution -
> > so also from unstable, experimental, etc. and even if packages are in
> > the NEW queue or people are just working in VCS these can be listes in
> > according sections).
> Yeah, my primary intention was to add polybori as a prospective package
> to the Blends web sentinel.
Well, this logis is not implemented (and I do not really see any need
for this). The released packages do have priority and once there is any
package entry found in the Debian package pool it is (by definition) no
prospective package. Even the design of the UDD importer for the
prospective package skips those packages that are just inside the
> > To get this working I really need your input
> > because even if I'm constantly watching ITPs, VCS commits etc obviously
> > packages are sliping through and are forgotten in the tasks files.
> The VCS for the updated package is here:
> Short and long description as well as the other information for the
> tasks page is already in the debian/control file, see here:
This can be easily fixed when the next upload to unstable is done.
I admit in times of freeze it could make sense to give the experimental
"release" some stronger preference because the information is in UDD
even right now:
udd=# SELECT source, distribution, release, vcs_type, vcs_url from sources where source = 'polybori' ;
source | distribution | release | vcs_type | vcs_url
polybori | debian | squeeze | |
polybori | debian | sid | |
polybori | debian | wheezy | |
polybori | debian | experimental | Git | git://git.debian.org/git/debian-science/packages/polybori.git
but in general giving sid preference over experimental seems to be a
safe decision (IMHO, feel free to discuss this on email@example.com
where it belongs).
So from my perspective the issue will be cured automatically after the
next upload to unstable and I personally do not feel motivated to spend
my time in tweaking the web sentinel to care for those kind of
exceptions - but patches are perfectly welcome.
Kind regard and thanks for the explanation anyway
PS: When I started writing I triggered the web sentinel creation
manually and noticed that
is proving me wrong: Experimental has in fact preference over
the other releases and I do regard *this* as a bug (according to
my previous arguments) because it hides the fact that there is such
a package inside the official Debian release. I hope I will find
the time to fix this as long as this is not "fixed" by an upload to