dear tilt,
On Wed, 04 Feb 2015, tilt wrote:
> Am 28.01.2015 um 00:19 schrieb tilt:
> > [...]
> > Right now I practise "+devuanX" re-versioning, so if I
> > encounter a hypothetical incoming package with name "xyz"
> > and version (in Jessie) "1.2.3-4" then my modified package
> > will still be
Am 28.01.2015 um 00:19 schrieb tilt:
> [...]
> Right now I practise "+devuanX" re-versioning, so if I
> encounter a hypothetical incoming package with name "xyz"
> and version (in Jessie) "1.2.3-4" then my modified package
> will still be called "xyz" and the version will be
> "1.2.3-4+devuan1" (a
On Friday, 30 de January de 2015 03:03:46 tilt escribió:
> Am 30.01.2015 um 03:49 schrieb Adam Borowski:
> > On Thu, Jan 29, 2015 at 09:39:19PM +, Noel Torres wrote:
> > [...]
> >
> >> Given that, if we pin our repository to 1001, it will
> >> always have bigger priority than Debian's, even if
Am 30.01.2015 um 03:49 schrieb Adam Borowski:
> On Thu, Jan 29, 2015 at 09:39:19PM +, Noel Torres wrote:
> [...]
>> Given that, if we pin our repository to 1001, it will
>> always have bigger priority than Debian's, even if Debian
>> version is higher than ours, and even if we are trying to
>>
On Thu, Jan 29, 2015 at 09:39:19PM +, Noel Torres wrote:
> On Thursday, 29 de January de 2015 18:10:10 Hendrik Boom escribió:
> > So the upgrade to devuan should perhaps introduce the pin?
> > And how soes that pinning work? Simply forbidding systemd and
> > some of its relatives? Or a way te
On Thu, Jan 29, 2015 at 09:39:19PM +, Noel Torres wrote:
> On Thursday, 29 de January de 2015 18:10:10 Hendrik Boom escribió:
> > So the upgrade to devuan should perhaps introduce the pin?
> > And how soes that pinning work? Simply forbidding systemd and
> > some of its relatives? Or a way te
On Thursday, 29 de January de 2015 18:10:10 Hendrik Boom escribió:
> So the upgrade to devuan should perhaps introduce the pin?
> And how soes that pinning work? Simply forbidding systemd and
> some of its relatives? Or a way te detect devuan packages and
> if they are present to ignore Debian's
On Wed, Jan 28, 2015 at 12:36:35AM +0100, Adam Borowski wrote:
> On Wed, Jan 28, 2015 at 12:19:38AM +0100, tilt wrote:
...
> > I do understand the "Bumping" problem you mentioned
>
> It's a problem only if you:
> 1. mix both Debian and Devuan apt sources, and
> 2. don't have pinning (/etc/apt/pref
Hi!
Am 27.01.2015 um 02:10 schrieb Noel Torres:
> On Sunday, 25 de January de 2015 00:04:32 tilt escribió:
> [...]
>> Question: How will volunteer version the new package?
>
> Hi tilt
>
> I think adding +devuan at the end of the package version was
> discussed, as well as changing the package name
On Wed, Jan 28, 2015 at 12:36:35AM +0100, Adam Borowski wrote:
[cut]
> >
> > I do understand the "Bumping" problem you mentioned
>
> It's a problem only if you:
> 1. mix both Debian and Devuan apt sources, and
> 2. don't have pinning (/etc/apt/preferences) in use
>
If I can add my two cents
On Wed, Jan 28, 2015 at 12:19:38AM +0100, tilt wrote:
> Right now I practise "+devuanX" re-versioning, so if I
> encounter a hypothetical incoming package with name "xyz"
> and version (in Jessie) "1.2.3-4" then my modified package
> will still be called "xyz" and the version will be
> "1.2.3-4+dev
[This is a double-post due to an identity mistake, my apology
to the moderators.]
Hi!
Am 27.01.2015 um 02:10 schrieb Noel Torres:
> On Sunday, 25 de January de 2015 00:04:32 tilt escribió:
> [...]
>> Question: How will volunteer version the new package?
>
> Hi tilt
>
> I think adding +devuan at t
On Sunday, 25 de January de 2015 00:04:32 tilt escribió:
[...]
> Question: How will volunteer version the new package?
Hi tilt
I think adding +devuan at the end of the package version was discussed, as
well as changing the package name to avoid that a bump in Debian's version
crushes our packag
Good timeofday,
I am new to this list, and I beg your pardon should this matter
already have been addressed.
Please consider this simple example scenario: Volunteer intends
to provide a modification of a Debian package "xyz", where the
modification is to drop a dependency on systemd (& co.).
Su
14 matches
Mail list logo