Re: Of the use of native packages for programs not specific to Debian.

[Goswin von Brederlow]

Jonathan Yu  writes:

> I agree that debian/ files likely don't cause a "whole lot of trouble"
> to us (it should only be a line to remove it using debian/rules prior
> to building? but I'm not 100% sure on that). However, I don't think
> that it not being tremendously burdensome on us in Debian is
> sufficient justification to permit or encourage this behaviour.
>
> On Wed, Sep 16, 2009 at 4:41 AM, Goswin von Brederlow  
> wrote:
>> Wouter Verhelst  writes:
>>
>>> On Mon, Sep 07, 2009 at 11:22:30AM +0200, Giacomo A. Catenazzi wrote:
 We have a lot of troubles when upstreams ship a debian/ directory
 in upstream tarball, thus I'll expect derivatives will have similar
 problems
>>>
>>> I don't see it that way.
>>>
>>> The reason why we have 'a lot of troubles' when upstreams ship a debian/
>>> directory, is because upstreams usually supply that directory as a
>>> courtesy to make life 'easier' for those people who want to build a
>>> Debian package out of their SCM repository, and that as a result, they
>>> are usually not even remotely Policy-compliant. Thus, we need to do a
>>> *lot* of work to get them integrated properly; and any files that keep
>>> lying around in debian/ might interfere with other things.
>>
>> And that quickly goes away when upstream accepts patches that fix
>> their debian directory.
>
> I am both the upstream maintainer of several Perl modules, for which I
> am also one of the Debian package maintainers. I personally am just
> pragmatic, and provide only what is necessary at various points -- so,
> upstream packages contain what is necessary to install via the
> standard Perl-ish way (CPAN shell), and the Debian packages contain
> this plus some Debian-specific stuff.
>
> One of the issues I would have with putting debian/ files upstream
> (beyond just being unexpected by the user since it's probably very
> uncommon in the wild) is that I would need to sync changes that the
> other pkg-perl team members submit, since we maintain packages as a
> team. It just seems a whole lot of work for little gain.

But that is because you have 2 seperate repositories. One for upstream
and one for the debian perl team. You are upstream but the debian-perl
team is the maintainer. That you are also a member of the debian-perl
team is just a coincidence muddying the waters. So I don't think your
case falls under the upstream == maintainer case.

>> I don't see that as a *lot* of work at all. It just means you need a
>> good relationship with upstream so changes to the debian dir are
>> merged upstream quickly. If you have write access to upstreams RCS
>> then I don't see this as a problem at all.
>>
>>> Debian packages from the Debian distribution usually are
>>> policy-compliant and maintained, so this kind of problem does not
>>> manifest itself as often for our downstreams
>>
>> And as we were talking about packages where the debian maintainer is
>> also upstream this problem also doesn't manifest for Debian itself.
>>
>>> (of course there are packages that are not maintained nor
>>> policy-compliant, but then they don't tend to live long in the
>>> distribution).
> And the problem is that users really don't know which is which, so
> upstream is just being a jerk and confusing their users :). Not to
> mention that it would reflect badly on our packages in Debian, as
> people would say, "damn Debian packages, this one wouldn't even build,
> it sucks!!!"
>
> I think someone (tm) should do a study and see just how difficult it
> is to deal with debian/ files in an upstream tarball. I take it that
> our scripts probably handle this sort of thing transparently, or that
> the effected files are removed prior to build time.

If upstream == maintainer then why would there ever be an upstream
release without a debian release? If you have done all the work of
fixing bugs or adding features and released a new version then running
debsign + dupload is really not complicated. I would assume people
would always do that for releases. Maybe not for dev snapshots, they
might just be for testing prior to uploads. But then those should be
clearly recognisable as such. It takes verry little effort to use a
clear versioning scheme.

MfG
Goswin


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

Re: Transitional (dummy) packages considered silly

[Goswin von Brederlow]

Magnus Holmgren  writes:

> When a binary package is renamed or split, as well as if several packages are 
> merged under a new name, transitional packages are normally created, which 
> depend on the new packages, which in turn Replaces and Conflicts with, and 
> possibly Provides, the old packages. I find those dummy packages as silly to 
> create as to uninstall after upgrading.

Dpkg has the ability to vanish empty packages. A dummy package should
be completly empty and not even contain a /usr/share/doc/. That way on
installation the package pulls in its depends and then vanishes. So no
more need to uninstall after upgrading. This only works if the
superseeding packages Provide the old one though. Otherwise depends on
the old package would become unsatisfied.

Only problem is that this screws with the automatic/manual install
flag. See below.

> I propose a new control field called e.g. Supersedes that will provide the 
> same semantics. In its simplest form, a renamed package will declare that it 
> Supersedes the old package name. That will be considered equivalent to 
> conflicting with/replacing earlier versions of the superseded package, as 
> well 
> as providing a new version of it, just like a dummy package. Multiple 
> packages 
> can supersede the same package (but they should probably be the same 
> version), 
> and one package can of course supersede many others.
>
> This proposal should be feasible; APT scans all Packages lists searching for 
> the best version of a given package to install, doesn't it? so it will be 
> able 
> to find the Supersedes fields at the same time.
>
> This would, among other things, solve the git problem; gnuit would supersede 
> git, which would tell APT that the latter should be upgraded into the former, 
> and that git the VCS is something else entirely.
>
> -- 
> Magnus Holmgrenholmg...@debian.org
> Debian Developer 

Packages should tell when they superseed some other package. The
conflicts/replaces/provides triplet was used for this in the past but
no frontend ever looked for it. Also not every superseeding has used
the triplet or should use it.

I suggest that superseeding also includes a possible version as a
package might only superseed an old version of something but not a
newer one. Or a rename might be undone resulting in A superseeding B
and B superseeding A. A version will tell the right order.


Superseeding should also preserve the automatic/manual flag of the
superseeded package. Currently if A was manually installed and becomes
a dummy package then removing A will propose to remove the
superseeding package too. WOrse if A vanishes as the superseeding
packages would just silently appear in the removable list.

MfG
Goswin


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

Re: Transitional (dummy) packages considered silly

[Goswin von Brederlow]

Pierre Habouzit  writes:

> On Thu, Sep 17, 2009 at 11:52:23PM +0200, Magnus Holmgren wrote:
> Note that transitional packages are seamless for users. When users has
> foo in $stable, and foo gets renamed into bar in $stable +1, then there
> is that:
>
> $stable: package foo
> $stable + 1: foo Depends bar, bar {replaces foo, provides foo, conflicts foo}
> $stable + 2: foo is dropped, replaces/provides/conflicts foo in bar can be 
> dropped.
>
> After user has upgraded from $stable to $stable + 1, he doesn't have
> 'foo' anymore.

Yes, he does. Till he removes it manually currently.

> Finally, I think your proposal doesn't work, because "Supersedes" cannot
> work if two distinct binary packages "Supersedes" the same binary. We
> can obviously ensure this doesn't happen in the _same_ Debian
> distribution. I don't see how we can feasibly ensure it across different
> releases in a sane way (and I know lots of people having deb lines for
> stable, testing and sid in their sources.list).

Why? The frontend would say "Foo is superseeded by multiple packages:
Bar, Baz, Buzz. Which one do you want?". Compare that to apt-get
giving a list of packages providing a virtual package when one tries to
install one.

MfG
Goswin


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

Re: Transitional (dummy) packages considered silly

[Goswin von Brederlow]

Magnus Holmgren  writes:

> When a binary package is renamed or split, as well as if several packages are 
> merged under a new name, transitional packages are normally created, which 
> depend on the new packages, which in turn Replaces and Conflicts with, and 
> possibly Provides, the old packages. I find those dummy packages as silly to 
> create as to uninstall after upgrading.
>
> I propose a new control field called e.g. Supersedes that will provide the 
> same semantics. In its simplest form, a renamed package will declare that it 
> Supersedes the old package name. That will be considered equivalent to 
> conflicting with/replacing earlier versions of the superseded package, as 
> well 
> as providing a new version of it, just like a dummy package. Multiple 
> packages 
> can supersede the same package (but they should probably be the same 
> version), 
> and one package can of course supersede many others.
>
> This proposal should be feasible; APT scans all Packages lists searching for 
> the best version of a given package to install, doesn't it? so it will be 
> able 
> to find the Supersedes fields at the same time.
>
> This would, among other things, solve the git problem; gnuit would supersede 
> git, which would tell APT that the latter should be upgraded into the former, 
> and that git the VCS is something else entirely.
>
> -- 
> Magnus Holmgrenholmg...@debian.org
> Debian Developer 

What about a case where the superseded package remains in Debian. To
bring up an example from the past: You have both apache and
apache2. apache2 superseds apache but apache is still available and
apache2 is not just a rename but a new package providing a superior
implementation of the older package.

Could supersede be made to detect such a case? Frontends should
suggest updating to apache2 but not force this or do so automatically.

Maybe only supersedes + provides would go automatically and superseds
alone would onyl suggest the update.

MfG
Goswin


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

Re: Transitional (dummy) packages considered silly

[Raphael Hertzog]

On Sun, 20 Sep 2009, Pierre Habouzit wrote:
> So while I dismissed your idea at first thinking you wanted to make it a
> dpkg thing, now that I understand that you rather want it to be an /apt/
> one, it makes really more sense to me.

I also believe that it's something that would be nice to have.

> The point remains though that:
>   - apt
>   - dselect
>   - aptitude
>   - cupt
> must support that.

I wouldn't put dselect on a blocker list for this feature. All the apt
based tools should support it however (that also includes synaptic).

> Well, so, maybe you should try to talk to apt/aptitude/dselect/cupt
> guys to see what they think of the proposal :)

I would add the required support in dpkg/dpkg-dev to make the field
official if Apt maintainers were to implement some support of it.

However I wonder if we should not generalize this so that we can add
supplementary hints for package managers in the future... there might
other kinds of information that could be used in optimizing upgrade paths.

I know Ubuntu has their own upgrade tool (update-manager -d) precisely to
be able to drive the upgrade more finely (sort of automatization of the
order recommended in the release notes).

Apt-Hints: supersedes ...

Other possible hints:
- no-auto-remove: for kernels, modules, firmwares (currently a hack in
  apt-get)
- no-mark-auto: for metapackages so that the direct dependencies installed
  are not marked as automatically installed

I'm sure we can come up with other over time, so it might be nice to have
a generic solution right from the beginning.

Cheers,
-- 
Raphaël Hertzog


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

link to link

[webmaster kaur]

add me on g talk..
dear.


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

Bug#548069: ITP: asciiportal -- puzzle jump'n'run adventure game

[Peter Pentchev]

Package: wnpp
Severity: wishlist
Owner: Peter Pentchev 

* Package name: asciiportal
  Version : 1.0
  Upstream Author : Joseph Larson
* URL : http://cymonsgames.com/asciiportal/
* License : MIT/X11
  Programming Lang: C++
  Description : puzzle jump'n'run adventure game
   Grab your hand-held portal device and enter the test chambers for a
   non-euclidean good time.
   .
   ASCIIpOrtal is a text based puzzle game inspired by the popular video
   game.  In ASCIIpOrtal you overcome challenges by placing portal
   way-points, joining two points in the map. If the player or any object
   passes through one portal way-point it will seamlessly exit the other.
   Since both way-points are the same point on the map the player's view
   through the portal reflects this and space warps around you as you pass
   through the portal.

I intend to maintain this package within the Debian Games Team.

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.netr...@space.bgr...@freebsd.org
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
I am not the subject of this sentence.


pgp6xmsP4kGeP.pgp
Description: PGP signature

Bug#548070: ITP: libpdcurses0 -- X/Open curses library with an X11 and SDL interface

[Peter Pentchev]

Package: wnpp
Severity: wishlist
Owner: Peter Pentchev 

* Package name: libpdcurses0
  Version : 3.4
  Upstream Author : William McBrine 
* URL : http://pdcurses.sourceforge.net/
* License : Public domain, MIT, GPL-2+
  Programming Lang: C
  Description : X/Open curses library with an X11 and SDL interface

The main reason I want to package this library is that asciiportal
(in a separate ITP) uses its SDL bindings for its weird half-TUI,
half-GUI :)

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.netr...@space.bgr...@freebsd.org
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
When you are not looking at it, this sentence is in Spanish.


pgp1iL0GQtRgA.pgp
Description: PGP signature

Re: zendframework package with or without bin package

[Raphael Geissert]

Jeremiah Foster wrote:

> 
> On Sep 23, 2009, at 1:22, Raphael Geissert wrote:
> 
>> Frank Habermann wrote:
>>>
>>> I also want to rename the package to libphp-zendframework.
>>>
>>
>> biased answer: ugh, why?
>> That reminds me some of the libfoo-bar-moo-invent-something-else-here
>> packages we have in the archive.
> 
> One possible answer to "why?" is that libfoo-bar-baz allows users easy
> access to a debian package that directly corresponds to the upstream
> software.

Yes, but the Zend Framework is "the" Zend Framework. Zend being the company
behind its development and behind the engine used in PHP it is somewhat
explicit and obvious.
The risk for a namespace collision in this case is minimal (if not zero),
and prefixing it with libphp- just makes the name uselessly longer. Not to
mention that it is a framework, not just a library.

Btw, some stats:
8089 packages with 0 dashes
10243 packages with 1 dashes
6068 packages with 2 dashes
1547 packages with 3 dashes
230 packages with 4 dashes
48 packages with 5 dashes
14 packages with 6 dashes
1 packages with 7 dashes

(sid/main/i386)

Cheers,
Raphael Geissert



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

Re: zendframework package with or without bin package

[Raphael Geissert]

sean finney wrote:

> On Tue, Sep 22, 2009 at 06:22:20PM -0500, Raphael Geissert wrote:
>> > 
>> > I also want to rename the package to libphp-zendframework.
>> > 
>> 
>> biased answer: ugh, why?
>> That reminds me some of the libfoo-bar-moo-invent-something-else-here
>> packages we have in the archive.
> 
> the php policy draft recommends something along these lines as well,

I know, and it still mentions some php.ini munging IIRC.

> though in practice i think there are more php[N]-foo than there are
> libfoo-php[N]. while originally the intent was to seperate extensions and
> php libraries into two seperate naming conventions, it doesn't seem like
> this is realistic or worth the effort to try and police.

php-foo has been being used for extensions
php-foo for pear modules (although there are a couple of non PEAR packages
using that naming IIRC)
libphp-foo and libfoo-php for libraries
and some weird combinations such as libfoo-php (which I think are
extensions).

But frameworks are the exception: cakephp, horde3, and the odd case of
php5-symfony1.0.

Cheers,
Raphael Geissert



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

Re: Patch Tagging Guidelines (aka DEP3)

[Kurt Roeckx]

On Mon, Sep 07, 2009 at 11:03:37PM +0200, Raphael Hertzog wrote:
> 
> You are welcome to share your feedback about this format on -devel, if we
> identify shortcomings or possible enhancements, we can still update
> the proposal (but only after we had time to get some real feedback
> based on actual usage of this format).

For elfutils, I have 2 patches that I take from the upstream git
repo.  Both patches have their own branch, and upstream/redhat
merges the master branch into them.  So around the time of an
upstream release I do git diff release...branch to get the new patch.

Those branches contain several patches, so it's not a single
commit.  And I'm not sure how to properly put in the header
where it comes from.


Kurt


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

Bug#548083: ITP: xen-orchestra -- Web-based Xen administration tool

[Damien Leone]

Package: wnpp
Severity: wishlist
Owner: Damien Leone 


* Package name: xen-orchestra
  Version : 0.12
  Upstream Author : Olivier Lambert 
* URL : http://xen-orchestra.com/
* License : GPL-2
  Programming Lang: PHP, AJAX
  Description : Web-based Xen administration tool

Uses RPC calls to Xen daemon to provide simple and clear interface for VM's 
management.
Based on PHP/Ajax/SQL and can contact every accessible Xen deamon accross the 
network.



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

Re: Debian marketing team

[Levenfus]

Hallo

Am 22.08.2008, 15:37 Uhr, schrieb Andreas Schuldei :


Hi everybody!

The Debian Marketing Team is real. It just didnt get alot rolling yet
and no processes in place to work on anything.

But better late then never!


We look for people (both Debian Developers, Maintaners or Users)
around the world who are interested in helping.

  * It would be good to collect Debian related News centrally (wiki)
and depending on its content and impact spread them locally or  
globally.


  * We need to put together plan and understand both who uses
Debian and where Debian would fit in well and should be used.
For that we need marketing savvy people. We want to meet and work on
this. Have you been to Extremadura yet? Do you want to go there?
Sightseeing not included.


We started putting together ideas at http://wiki.debian.org/Marketing,
will use the existing mailing list debian-public...@lists.debian.org
and the irc channel #debian-marketing on irc.debian.org for  
communication.


Moritz and Andreas





--
Mit freundlichen Grüßen
Levenfus


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

Re: Of the use of native packages for programs not specific to Debian.

[Russ Allbery]

Goswin von Brederlow  writes:

> If upstream == maintainer then why would there ever be an upstream
> release without a debian release?

It's rare for there to be an upstream release without a Debian release,
although it can happen during freezes or with frequent dev releases.  It's
very, very common for there to be a Debian release without an upstream
release, which is more where the problem is.  Going through all the normal
upstream release process when there was just a minor change to the
packaging files is really a waste of time, and then what happens is that
there's a temptation to not fix packaging problems until one gets around
to making another upstream release.

I went through all this with my own packages for which I'm upstream and
found that keeping the packaging separate from the upstream distribution
was way more convenient and useful for me.

-- 
Russ Allbery (r...@debian.org)   


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

Re: Transitional (dummy) packages considered silly

[Russ Allbery]

Goswin von Brederlow  writes:

> Dpkg has the ability to vanish empty packages. A dummy package should
> be completly empty and not even contain a /usr/share/doc/.

Such a package is explicitly forbidden by Debian Policy.  You need to
propose a Policy change if you want to do this.  I believe it was
discussed some time past, and the general consensus was against doing
this, but I could be misremembering.

-- 
Russ Allbery (r...@debian.org)   


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

Re: Of the use of native packages for programs not specific to Debian.

[Manoj Srivastava]

On Wed, Sep 23 2009, Russ Allbery wrote:

> Goswin von Brederlow  writes:
>
>> If upstream == maintainer then why would there ever be an upstream
>> release without a debian release?
>
> It's rare for there to be an upstream release without a Debian release,
> although it can happen during freezes or with frequent dev releases.  It's
> very, very common for there to be a Debian release without an upstream
> release, which is more where the problem is.  Going through all the normal
> upstream release process when there was just a minor change to the
> packaging files is really a waste of time, and then what happens is that
> there's a temptation to not fix packaging problems until one gets around
> to making another upstream release.
>
> I went through all this with my own packages for which I'm upstream and
> found that keeping the packaging separate from the upstream distribution
> was way more convenient and useful for me.

And that, I think, may serve as a guiding criteria for whether
 one should make a package native or not. With my native packages
 (kernel-package, ucf, and devotee), I do not _have_ an upstrem process,
 nor an upstream "distribution" or tarball; and thus there is no
 difference in process for a packaging change or a feature addition --
 which makes it clear to me that these are native packages.

So if the "upstream release" has a life of its own, distinct
 from a Debian package upload, you probably do not want native packaging
 even if you, as a DD, are upstream.

manoj

-- 
Gee, Toto, I don't think we're in Kansas anymore.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Of the use of native packages for programs not specific to Debian.

[Emilio Pozuelo Monfort]

Manoj Srivastava wrote:
> And that, I think, may serve as a guiding criteria for whether
>  one should make a package native or not. With my native packages
>  (kernel-package, ucf, and devotee), I do not _have_ an upstrem process,
>  nor an upstream "distribution" or tarball; and thus there is no
>  difference in process for a packaging change or a feature addition --
>  which makes it clear to me that these are native packages.

Whenever you guys bring the argument of convenience to make a package native, I
imagine that RedHat, Novell and company did the same with half of GNOME
packages, and I had to look at Fedora and SuSE's pages checking for updates,
report bugs in their bugzillas, look if a new upstream version only changed the
spec file or also the code, and I want to cry myself to sleep.

Emilio



signature.asc
Description: OpenPGP digital signature

Bug#548092: RFP: php-qt -- Object-oriented interface to the Qt4 Framework.

[Ivan Borzenkov]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

--- Please fill out the fields below. ---

   Package name: php-qt
Version: 0.9
Upstream Author: Thomas Mönicke
URL: http://www.php-qt.org/
License: GPL
Description: PHP Object-oriented interface to the Qt4 Framework.


signature.asc
Description: This is a digitally signed message part.

Re: Transitional (dummy) packages considered silly

[Guillem Jover]

On Wed, 2009-09-23 at 10:51:50 +0200, Goswin von Brederlow wrote:
> Magnus Holmgren  writes:
> > When a binary package is renamed or split, as well as if several packages 
> > are 
> > merged under a new name, transitional packages are normally created, which 
> > depend on the new packages, which in turn Replaces and Conflicts with, and 
> > possibly Provides, the old packages. I find those dummy packages as silly 
> > to 
> > create as to uninstall after upgrading.
> 
> Dpkg has the ability to vanish empty packages. A dummy package should
> be completly empty and not even contain a /usr/share/doc/. That way on
> installation the package pulls in its depends and then vanishes. So no
> more need to uninstall after upgrading. This only works if the
> superseeding packages Provide the old one though. Otherwise depends on
> the old package would become unsatisfied.

That's not correct. dpkg only disappears packages that have been
completely replaced while installing other packages. There's two cases
for this:

 1. The package to disappear has files that get completely replaced by
the new one. Needs the Replaces field.
 2. The disappearing package contains empty directories, and all of
them are shipped as well by the new package. Does not need
Replaces field, because directory takeover is an implicit
Replaces, so this is actually a subcase of 1.

dpkg will never disappear a packages just because it's empty w/o the
previous conditions. And just to clarify, in no case the Provides field
plays any role in the disappearing process.

regards,
guillem


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

Re: Of the use of native packages for programs not specific to Debian.

[Manoj Srivastava]

On Wed, Sep 23 2009, Emilio Pozuelo Monfort wrote:

> Manoj Srivastava wrote:
>> And that, I think, may serve as a guiding criteria for whether
>>  one should make a package native or not. With my native packages
>>  (kernel-package, ucf, and devotee), I do not _have_ an upstrem process,
>>  nor an upstream "distribution" or tarball; and thus there is no
>>  difference in process for a packaging change or a feature addition --
>>  which makes it clear to me that these are native packages.
>
> Whenever you guys bring the argument of convenience to make a package
> native, I imagine that RedHat, Novell and company did the same with
> half of GNOME packages, and I had to look at Fedora and SuSE's pages
> checking for updates, report bugs in their bugzillas, look if a new
> upstream version only changed the spec file or also the code, and I
> want to cry myself to sleep.

I think you have not looked at the details of what I said: very
 little of my argument has to do with convenience; it has to do with
 artifacts of a separate upstream entity. If the package does exist as an
 upstream entity, it will be reflected in the processs; and the lack of
 such a process (having an upstream tarball that is available separate
 from the debian upload, for instance) serves as a hint. Convenience has
 little to do with it.

manoj
 ps: The new devotee package, for instance, is unlikely to remain a
 debian native, since it would make sense to have it not tied only to
 debian. Again, convenience does not enter the equation.
-- 
linux: the choice of a GNU generation (k...@cis.ufl.edu put this on
Tshirts in '93)
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Bug#548131: ITP: libmoosex-async-perl -- Moose metaclasses to support asynchronous operations

[Jonathan Yu]

Package: wnpp
Owner: Jonathan Yu 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libmoosex-async-perl
  Version : 0.07
  Upstream Author : Chris Prather 
* URL : http://search.cpan.org/dist/MooseX-Async/
* License : Artistic | GPL-1+
  Programming Lang: Perl
  Description : Moose metaclasses to support asynchronous operations

 MooseX::Async is a set of Metaclasses for MooseX::POE (see libmoosex-poe-perl)
 and it's siblings. As such, it is porbably not very useful on its own. Please
 see them for documentation.

NOTE: this is needed for MooseX::POE, which is in turn required for
the upgrade of POE::Component::Server::SimpleHTTP



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

Bug#548136: ITP: libmoosex-poe-perl -- Moose wrapper around a POE::Session

[Jonathan Yu]

Package: wnpp
Owner: Jonathan Yu 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libmoosex-poe-perl
  Version : 0.205
  Upstream Author : Chris Prather 
* URL : http://search.cpan.org/dist/MooseX-POE/
* License : Artistic | GPL-1+
  Programming Lang: Perl
  Description : Moose wrapper around a POE::Session

 MooseX::POE is a Perl module that provides a Moose-ish way to manipulate
 POE::Session instances. It provides an 'event' keyword to associate events
 with a given block of code. The current session will then be able to run
 these events in the normal fashion, whilst providing the encapsulation and
 other nice features afforded by Moose.



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